How Litmus Uses Integrate.io to Enable Company-Wide Reporting

Hello. Welcome to another s x four summit presentation brought to you by xPlani. And today, we're excited to have one of our customers, Safiya Moran, who works for Litmus, which is a company that makes software that enables email marketing. And Safia is going to tell us how, Witness is integrating their Salesforce instance and perhaps other of their data sources, using Next Plenty. So without further ado, here's Safia.

Thank you.

Yep, as Leonard said, I talk a little bit about how Litmus is using xPlanet to enable a company wide reporting.

So first off, I want to kind of talk about what our challenge was we were solving for.

This was unique to our company, but I imagine that other companies and other customers out there probably experienced something similar.

So when I joined Litmus in twenty sixteen, it was a pretty small company. We were about thirty employees.

And when I was hired on in twenty sixteen, I was the very first data hire.

So we were starting very much from scratch in the data world. And over the next couple of years, we built that data and analytics team out. And as part of that, we started building out a more robust data warehouse.

We added on data translation layer, and we started building out a bunch of dashboards and reports and even modeling built on top of all that data in our data warehouse.

And then we got to twenty nineteen and as we were doing building all this stuff out in twenty seventeen and twenty eighteen, there was a lot of other stuff happening in the company. And we got to twenty nineteen and found ourselves at a point where we needed to really overhaul the majority of the assets we had built out in the data and analytics team.

So to give you an idea of kind of what happened in the business that brought us to that point in twenty nineteen is starting in twenty sixteen, ninety five percent of our revenue was coming from self serve customers. So folks that were just coming directly to our site and signing up for an individual plan.

Over the next few years though, Litmus started investing heavily in the direct sales channel. And as a result, that part of the business grew.

However, back in twenty sixteen and twenty seventeen, when we were building out our data warehouse and that data translation layer and creating all of our business metrics from that data, because it was such as the direct sales part was such a small portion, We weren't building that out to scale. You know, we were focused on the self serve piece because that was where the majority of the revenue was.

Well, we got to twenty nineteen and found that fifty percent of our revenue now came from direct sales and we had no reporting around it. All the reporting that existed, our entire data warehouse was all focused on self serve.

So that brings us to challenge number one we're solving for. We needed to incorporate the direct sales side, and into our reporting.

And the challenge is the first challenge we came up against was that the data for direct sales did not exist in our data warehouse. We already had our internal backs and system and our billing system, which was what we used to build everything out for the self serve business. Those were already in our data warehouse, but we didn't have anything from Salesforce in our data warehouse. And that's where almost all of the data we needed to be able to report on the direct sales business flipped.

And then challenge number two that we were facing was aside from getting data out of Salesforce and into the data warehouse in order to build out that translation layer and those business metrics, We also wanted to push data to the sales team in Salesforce.

So there were a lot of derived fields that we had created in our data warehouse and in that translation layer, derived fields such as we had done modeling around health score and stuff, plan information for existing self serve customers, things that would be really helpful for us to be able to pass to the sales team when they're working those leads out of Salesforce.

And then there was the other data systems that we had already connected into our data warehouse that also weren't talking to Salesforce. So there was also that piece there that we wanted to pass some of that information into Salesforce as well.

So these were the two primary challenges that we were faced with when we got to late twenty eighteen, early twenty nineteen. So we went out looking for what was the solution to this? And we started our hunt for a tool that would enable us to incorporate that Salesforce data into our data warehouse.

So when we were looking for it, we were looking for a few different things in this solution. So first of all, we wanted something with a native Salesforce integration, which at the time that we were looking was a lot harder to find than we thought it would be. But on the data and analytics team, while we all consider ourselves pretty tech savvy, none of us are engineers building a REST API connection just wasn't something that was in our wheelhouse.

So we needed something that was already built in with that Salesforce integration.

We also needed the bi directional data sync. So as I mentioned, the two challenges we're solving for, we needed to push data to Salesforce and get data out of Salesforce.

We also needed the scheduling capability. So we needed to be able to set it up on a regular cadence so that every night we're pulling down information from Salesforce that is then that translation layer and all those views are being created and cached on the back end of our data warehouse.

And then something that was intuitive and easy to use. So as I mentioned, the data and analytics team, definitely tech savvy, but we're not engineers. And there were several products that we trialed that, quite frankly, just couldn't figure out how to use without quite a bit of support.

So we wanted something that we could get in there. We could set up everything without having to rely on getting engineering resources for.

So we came across X Plenty and X Plenty really checked all these boxes for us. It was definitely easy enough for us to do, easy enough to get that Salesforce connection set up.

And we've continued to be able to use it easily with just the data and analytics team maintaining that. So the solution to the particular challenges we had were, first of all, getting that Salesforce data to our warehouse. Xplanning makes it really easy for us to copy those Salesforce objects directly into our data warehouse, which is a Redshift warehouse as we could just bring them in as tables.

It's very easy. We have it run every night. It just overwrites those tables every night and recreates them in our warehouse.

And now that we have all those Salesforce objects in the data warehouse, that gives us the missing piece that we needed to have that raw data. And now we can do all the translation layer, we can convert those to all the business metrics. And so now we have all that for the direct sales side, as well as on the self serve side.

And then challenge two, the solution to that was also easy with X Plenty. It does have that bi directional sync. So we are able to pass data back into Salesforce.

So some of the things we are doing currently to pass data into Salesforce is for accounts that are existing self serve customers, we're able to pass information about that account and their current plan information into Salesforce.

We're passing different product usage metrics and from a graphic fields, as well as we've built out some health score models that we're able to, you know, we flagged certain accounts based on that and we can pass that metric over to Salesforce as well. So now it's accessible to the sales team in Salesforce.

And then there's a couple kind of added bonuses. These weren't things that we were looking for when we were started, you know, looking for a solution and a tool, but there are things that X Plenty that has allowed us to do, that had been really beneficial.

So now that we have the Salesforce and Redshift Data Warehouse sync, we've actually been able to automate several of this sales ops tasks. So these were things that our sales ops specialist was doing manually every week, and it would take hours to complete these tasks. And it was things that you know, just updating data on specific accounts and specific opportunities. And we are able to automate that now using packages and xPlanning.

And we're also doing some quality control reporting. Now that we have the Salesforce data and our billing system data all within our data warehouse, it's easy to do cross checks to make sure like plan information is matching up between the two and stuff. So we use it also to run some regular QC reporting.

So along the way, there were a few things we learned that hopefully will help other people setting up a similar setup. So the number one thing I would say we've learned was that communication with your Salesforce admin is essential. So you're of course going to be working with them when you do the initial setup and you get the initial connections created. And probably when you're creating the initial packages as well and figuring out what you're writing to.

But once you get all that set up and it's just kind of running nightly, you've got it scheduled and it's fairly hands off, that communication needs to continue. We've run into issues where, they'll be making changes to objects in Salesforce and not necessarily considering the downstream impact that might have.

And it'll end up causing our job and package to fail.

And it's usually a pretty easy fix, but it's never great to not find out about it until something fails, right? So maintaining that line of communication is really important.

The second is just considering timing carefully. So there are timing aspects to kind of all the steps. There's our data warehouse has a translation in the translation views.

Know, things happen at a certain time. And so we want to time the packages carefully so that we're getting the freshest data and passing the freshest data between sources. Since for a lot of things, we have it set up only nightly.

And it is possible to set it up at more frequent intervals. But if you're doing it only like maybe at a twenty four hour interval, you want to make sure that they you are passing is as fresh as possible at that point in time. So it's not a bigger lag.

And then third is using a designated login or user for both ends. So for this, that meant creating a specific user called xPliny API user in Salesforce.

And this makes the kind of auditing and the troubleshooting just so much easier when you can tell exactly which system you know created a record in Salesforce or changed a field.

So this makes that audit trail a lot easier. That's what I've got. Thank you so much.

Hopefully that will be helpful to some of you.

Thank you, Safiya. I've got a few questions. First off, I just have to underline that out. That's really smart to assign a user as your exponent user. So when somebody sees something happening in Salesforce, it's not under somebody's name and then it's like, did so and so do such and such?

Yes.

Tell me a little bit about the communication with your Salesforce administrator. When that person makes a change, do they write you an email list or do they call you up? How does that work?

Yeah, so we, our company, because a lot of us are remote, we do a lot of communication through Slack.

So it's usually just a quick Slack message, just, hey, heads up, I, you know, remove this field from this object.

They usually try to confirm with us first, like make sure it's not a field that we were using. In most cases, it's not. There's so many fields in our Salesforce instance that most of these are trivial.

So confirmation, we're not using that field and then just a heads up so we can update the package in xPlani.

That's good. So who normally writes the Xplanning transforms or data pipelines? Is it you? Is it somebody who works with you or?

Yeah, so it has typically been me.

The role I'm in now is actually a new role for me. So I was our senior data scientist up until February of this year. In that role, I was creating most of these and I've kind of maintained that as we've gone on, but there's been, we've empowered kind of everyone on our data and analytics team to create packages as they've seen as they need them. So I handle a lot of the Salesforce things, but some of the other data connections we have set up are handled by other folks on the data and analytics team.

Wow, so they're able to just pick it up and learn X Plenty without too much hassle?

Yeah, absolutely. It's pretty easy, especially if you have kind of a template or an existing package to go off of to kind of just take that copy it and tweak it to what you need. I'd say the hardest part for any of us to learn is just is that initial connection set up to any of the different systems. And once you get that right, and get the permissions right, it's very easy to learn and set up.

What kind of what reporting tool are you using on a Redshift or reporting tools to get your reports?

Yeah, so we use a tool. Was Periscope, it's now called a Sisense for cloud data teams, but that is we were an early adopter of that tool and they also maintain our Redshift data warehouse as well.

And that's and you're sticking with that? You think that's a good choice works well for your company?

We're we're pretty invested in it. We've built out quite a robust, you know, reporting portfolio in it. So we're pretty invested in it at this point.

So the other system, I guess it's a self serve system is the other system that was already in your data warehouse.

And that has its own loading procedure and everything that's not that wasn't done with Xplanning that was a that was a legacy right?

Correct yeah so we initially set up quite a few of the connections were possible through Periscope and they were able to pull those connect to our other systems, which, like our our back end self serve system is a MySQL database, for example. So we certainly could have pulled that in through X Plenty, but we are already have that set up.

And Periscope doesn't have a direct Salesforce connection or not make any sense. It wouldn't make any sense to do that anyway, right? Because you blow through your governing limits.

Right.

Well, this is a great example of, you know, how easy it is really to connect something up with X Plenty and Salesforce. And I think you're right.

As somebody who used Salesforce, your insight that it is strangely hard to find something that's both easy to use and powerful enough and bidirectional with Salesforce. So I'm glad you found X Plenty and I really appreciate your time today.

Thank you so much and, wish you success and good Thank you.

‍