Customer success story
Ten records for one hospital, and the middle table that fixed it
AliMed’s customer records multiplied. A hospital could exist ten times in Microsoft Dynamics AX, and its whole health system counted as a single customer, so nobody could tell which site was actually ordering. Rapidi connected AX to Salesforce through a mapping table that collapsed the duplicates without touching the ERP.
AliMed designs and distributes healthcare products, best known for custom “positioners” that hold anything from a single limb to a whole patient. After a previous integration attempt failed, Rapidi’s mirroring feature pushed a commercial list of US healthcare locations into Salesforce even though the source had no timestamps, and a custom SQL table tied many AX accounts to one Salesforce record. Grouping by delivery postal address turned a corporate blob into per-facility accounts.
Talk to an integration expert
The company
AliMed has been designing and supplying healthcare products since 1970, when Julian and Barbara Cherubini started selling from their home in Boston, not far from the company’s current headquarters in Dedham, Massachusetts. The first custom products, insoles and braces, launched in 1974.
A direct-mail model took it from there. The catalogues grew thick enough to become routine sights in hospitals, long-term care facilities, surgical centres, operating rooms and home care. The catalogue is online now, and still growing, along with the customer base.
The company is best known for custom-manufactured positioners — products that control the position of anything from a single body part up to the whole patient — and many of them can be ordered in custom sizes. More about the company at alimed.com.
Records that multiplied like rabbits
To support the sales team better than Microsoft Dynamics AX could on its own, AliMed had bought Microsoft CRM 2013 and contracted a third party to build a home-grown integration with AX. Jimmy Mathew was hired to upgrade the CRM and to deal with the data-integrity problems that came with it.
The biggest of those problems was duplication. An existing customer might visit the website and create a new account, which was added to AX rather than linked to the account they already had. Or they phoned in, customer service could not find the record, and a fresh one was created on the spot.
We had a data quality issue in our system, and we didn’t have the tools to solve it.
The original integration made it worse rather than better. “The Microsoft CRM just pulled records from AX, so that we would end up with all the duplicate records there as well,” Mathew says. “My goal, when I joined, was to ensure that we had both a CRM and integration that supported our needs better. Everything was on the table.” He found Salesforce had the better answer for managing customer data, and AliMed switched. The integration problem stayed exactly where it was.
The attempt that failed
This part of the story is worth telling honestly, because it is the reason the eventual requirements were so specific.
Mathew’s team first evaluated Jitterbit. It did not account for the quirks in AX and did nothing for the data-integrity problem; it wanted to synchronise record by record, which is precisely what produces duplicates at the far end. “Once we started to implement, we discovered all these restrictions, and it just turned out not to be feasible,” Mathew says. “Worse than that, when we did our first test, after 7 or 8 months of design and development, it failed miserably.”
The team knew by then that they did not want every AX customer record in Salesforce, because too many of them were duplicates. The plan instead was to import “Definitive Data”, a commercial list of every healthcare location in the United States, and map the duplicate AX records onto a single record per real place. That was more than the tool could do.
The solution
Rapidi turned up in Mathew’s research, and its mirroring feature did the thing that had blocked everything else: it pushed the Definitive Data customer records into Salesforce even though the source had no timestamp to synchronise against.
Around that, the team defined a SQL table in the middle. “We might have 10 accounts in AX, and we could tie that to one record in the middle table,” Mathew explains. Rapidi handled the custom configuration without complaint, and running it stayed simple: “We can just update one record in the middle table and have Rapidi run its job, and the change gets into Salesforce without a problem.”
The middle table also solved a legacy problem in the ERP. AX treated an entire healthcare group as one customer, even a large chain of hospitals. Grouping the middle-table records by delivery postal address produced meaningful Salesforce accounts at the level of the individual facility, with historical orders attached to the site rather than the controlling company.
That distinction matters commercially. Purchasing decisions for most items are made locally, so knowing which hospital is ordering what is the difference between focused sales effort and guesswork. Before, a report could only name the corporation that owned the health system, however many sites it contained.
One more bottleneck fell along the way. Pulling historical sales data into Salesforce through an AX list view worked but “took forever”. Rapidi consultants worked with the team on indexing the tables and found a better route to push the data, after which the historical load became quick.
Take it with you
The whole story as a PDF
Six pages: the records that multiplied, the eight months that ended in a failed first test, the middle table that mapped ten AX accounts onto one, and Jimmy Mathew in his own words. Yours after one short form.
Reflections
Mathew is direct about what he would tell someone at the start of this.
Initially, we were focused on the cheapest integration solution, anything that could connect AX to Salesforce. But, at times, the cheapest is not best. You need an integration partner that understands the quirks of the ERP, such as AX timestamps. With Rapidi, we are finally exchanging accurate data.
He also rates the unglamorous part — being able to report a problem and see it resolved. “We could submit a problem in the afternoon, and often by the time we got to work the next morning, we would have a solution.”
Asked what he would do without it, he laughs. “I can’t imagine that. Before Rapidi we couldn’t see errors and therefore couldn’t fix problems ourselves. We have so much visibility now. We can see the jobs being run, and can control them, and we have all the details of activities, including errors, in the logs. We can’t go back, we can only go forwards now.”
Duplicate customer records you cannot clean up?
Tell us what your ERP holds and how the duplicates got there, and we will tell you whether a standard Rapidi template covers you.