No one likes doing manual and repetitive tasks, or at least we don’t. That’s how our latest integration started. I’m on the IT team here at MuleSoft, and I noticed that our field team (i.e. anyone who makes commission based pay) was generating a large number of tickets based around distribution lists/email groups. The problem was simple: there had been no existing structure; each regional VP had set up their own groups; none of those groups had consistent names so they were also impossible to find; and most of the existing groups were inaccurate. The untidy structure meant that invariably every new field employee generated at least 2-3 tickets in order to refine the groups they were a member of.
This wasted a lot of time. We needed a better solution, ideally one that allowed the field team to have control over their own groups; after all, Joe in Sales knows what his role in the company is better than we in IT do.
The first step was to actually wrap some sanity around the groups, and to that end we designed a new group structure which was programmatically generated and nested. I’ve included a fictitious design below to help illustrate.
Under the proposed structure, if you are a member of Muley-Sales-NA-Account-Executives, then you are a member of Muley-Sales-NA and Muley-Sales. Imagine instead of just Muley-Sales-NA we have a Muley-Sales group per theater (APAC, EMEA, LATAM). To contact everyone, you can use just one group, but you can now also find a group just specifically represents the people you exactly intend to contact. This structure is clean and predictable; you can find anyone you need to logically without much effort.
Now that we had the groups, it was time to make them clean and accurate. We identified the systems of record (those which contain the most accurate information) for management level and sales role, or Workday and Salesforce respectively. We generated a Workday report which included everyone from the field organization and some metadata about the employees as our initial data stream. We used a unique arbitrary value populated on account creation to coordinate between the two systems. Once we have the employee data from both Workday and SFDC, we were ready to process the employee record. We developed some custom mapping logic to transform the aggregate of that data into our newly created group structure. Now that we had the corresponding group, we used an API call to our email service, in this case Google Apps, to add people to the correct groups. All of this was done inside of Anypoint Studio. It is currently running in our Cloudhub instance.
The MuleSoft product significantly accelerated the time to deployment for this project. Additionally, as we continue to implement more APIs into our environment, we can stop talking about “Workday reports” and start talking about “data sets from our employee API”. This makes the IT team more agile, and more adaptable to company needs and further improves the development velocity.