Davanti Dreamforce Digest #3: Integration insights
07th October 2021
Author Iain Falconer
Salesforce is an important and powerful tool that helps Davanti’s customers get closer to their customers, helping to create connected experiences for meaningful and sustainable outcomes.
A number of the Davanti team attended sessions at this year’s Dreamforce, learning more about updates to the tech stack as well as gaining insights into their particular areas of expertise – and then we asked them to share their insights and highlights as part of this #DF21 Davanti Digest series.
Iain Falconer and Manju Johnson share their integration and MuleSoft highlights and insights.
Tell us about the sessions you attended and what’s important about the topic of integration.
One of the main sessions was about creating integrated Customer 360 experiences with MuleSoft. This focused on how to integrate and automate with MuleSoft to create connected experiences. Across the sessions, the speakers also spoke about using APIs to integrate customer data with MuleSoft and Salesforce, analysing and acting on data, and robotic process automation (RPA).
The sessions were Salesforce-centric, of course, so they were more focused on the front-end user experience and the user interface as opposed to the technical functionality of MuleSoft. It was interesting that they highlighted how MuleSoft Composer is now very much part of the application, which makes sense as it offers IT infrastructure departments more integration capability. The main messaging was that businesses can integrate more, using Composer as a basis for this.
What were your highlights?
I found the RPA content quite interesting. I knew Salesforce had acquired a product in the space, but I didn’t realise it was going to fall under the MuleSoft brand. Again, RPA is all about automating integration through user interface functionality rather than back-end integration. Part of the messaging around this was that you can’t automate everything, and sometimes it makes sense to utilise what can be considered simpler tools. However, we also know the cost of maintaining robotic processes and interfaces can be challenging. They may be fine for old legacy systems that aren’t likely to change, but it becomes tricky with modern applications that are constantly evolving. It’s always about making sure the technology is fit for purpose. Regardless, it’s definitely an interesting capability that we need to start looking at for next year, when it will be released.
Another standout point of discussion was around the Financial Services Cloud. Salesforce made mention of a new accelerator to help businesses build out their financial integration with Financial Services Cloud. From a market standpoint, this helps to highlight the value proposition of MuleSoft within that sector, and it highlights that these accelerators can give a jumpstart for integration, meaning you can build on what has already been done, rather than reinventing the wheel.
What were your key takeaways from the sessions?
One thing that’s very important to note is that the marketing messaging around Salesforce and MuleSoft can sometimes imply an oversimplification of integration.
From a Salesforce point of view, MuleSoft Composer is promoted as a configurable integration tool that creates a lot of functionality as an administrator of the application. I think this is something we need to be cautious about, however, and be mindful not to oversimplify integration, and be careful in how we provide tools to people that don’t necessarily fully understand the implications of what they’re doing and the potential constraints.
For example, some of the marketing messaging would say how easy it is to drag, drop and put pieces together. I’m concerned that this removes the understanding that you also need a certain level of understanding or expertise. When it comes to using Composer to integrate with Slack, this is a relatively simple integration, so the messaging makes sense, but when you’re dealing with some of the more complex integration requirements, this perspective doesn’t offer the full picture.
A large part of the Salesforce world is configuration, so I understand they’re bringing MuleSoft into that space. But with a certain level of configuration, you also have limitations. I would say they’ve adopted a more customer-centric view of it, where the customers are those that don’t want code and don’t want to be building software. It’s always important to remember that MuleSoft is a product that’s come from a very technical development background. It’s growing and evolving into configuration and visualisation of designs rather than writing software, but we haven’t quite met in the middle. Overall, Dreamforce was more about the administration and configuration capability rather than some of the technical capabilities of MuleSoft, and while it was still valid it doesn’t speak to what is required to solve more complex problems.
What’s most relevant for New Zealand organisations?
It’s all about understanding that you know integrations will have complexity. We still need to consider that complexity and not think we can just plug it all in and it’ll magically happen.
If I think about some of the New Zealand organisations we work with, I often use the 80/20 rule to describe this concept. Ideally, 80% of your integration needs are very simple and you can achieve these relatively painlessly. But the 20% remaining may take 80% of the team to build, and you will still need to take the time to do the hard work and have the budget to deliver it. Integration capabilities are improving, for instance there are all kinds of use cases and templates available so we can build on a knowledge base and not from scratch, and there are also accelerators that have plug-and-play functionality out of the box, but we still need to be considering our accessibility to that capability.
Another big push for this year was Slack. Whether it’s Slack, Jira or another product, Salesforce is clearly pulling a lot of its ecosystem together, and using APIs and development to make the extra functionality easier to use. Slack is hugely valuable, and particularly in the New Zealand market where many organisations want to engage better with the communities around Salesforce, but don’t necessarily want to build out a lot of infrastructure to make that happen. I think it’s always about picking and choosing the use cases that are fit for purpose within the technology.
What left a lasting impression?
On the whole, I would say that businesses need to understand they shouldn’t jump in without first understanding what their use cases are, what their limitations are, and what their overarching aims are.
If you start on a small scale with smaller activities and use cases, you can begin to understand the limitations and either work around them or understand how you can create something more complete or robust. Ultimately, it’s all about understanding that you’re not necessarily going to get everything you want and it may be more complex than you realise, but if you can manage those expectations and those use cases accordingly you can achieve great capabilities and functionality.