MuleSoft at MuleSoft: Making email groups elegant

December 10 2015


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 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.

Now it is time to drive adoption of our shiny new groups. I could go through and manually check each group, then simply tell people they’re accurate, but I didn’t want to do manual labor! Instead, we turned again to MuleSoft’s product. This time we used a RAML spec to generate an API which accepted calls where you could specify either a group email address or a user email address. If the call specifies a user email, the API will return all the groups in the nesting structure that the user is a member of, if the call specifies a group email, the API will return all the people who are members of that group. We uploaded the API and its supporting project into Cloudhub as well, and ta-da! our documentation was self-writing. We wrote a little javascript to make the API calls and then stick everything on a page in our documentation repository and we were done.

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.

We'd love to hear your opinion on this post