Skip to content

MuleSoft Composer – Part III

4 Key Takeaways from Developing Solutions Using Composer


Over the last 2 weeks we have covered MuleSoft Composer through two excellent blogs by Pavan Kumar.

Having worked with Pavan on developing a go-to-market solution using Composer, some of our practical experience, what we’ve learnt through MuleSoft teaching and discussions builds nicely on those previous blogs.

So now we have a bonus 3rd blog for MuleSoft Composer – 4 Key Takeaways From Real Solutions Using Composer.

What is Composer?

As a quick recap MuleSoft Composer is a no-code integration tool from MuleSoft and Salesforce. Composer makes it easy to build process automation for data using clicks instead of code. It comes with a series of out-of-the-box prebuilt connectors that require authorisation login information, as you would for any application.

Composer is primarily aimed at System Administrators or Business Analysts who do not have detailed knowledge of Anypoint Platform, flow building or coding. It empowers people with systems and data knowledge to interconnect systems.

Composer is an event-driven tool, but not like traditional publish/subscribe applications, which have the ability to persist the data so as to enable asynchronous access and retries on failure. As such, composer is a non-intrusive component that allows specific data changes in an application to be published to a series of downstream target systems, without needing changes in the source or target.

In designing market solutions that use Composer, we’ve developed our good practices from experience. In learning the tool, we have answered common questions heard across the community when Composer is introduced.

This blog aims to highlight some good practices and how they have developed from answering these questions.

Note: this blog was written at the beginning of 2023. Composer is in evolution and development. Hence, through this evolution, the answers to these questions may vary.

What are the 4 key takeaways?

1. Where are the layers?

There aren’t any.

When presenting Composer to people with experience of the Anypoint Platform, they often reapply the principles of loosely coupled microservices with integration re-use. Arguably Composer is the opposite; point-to-point, tightly coupled integrations. 

From this, you could say, “Aren’t we going back to what APIs were trying to improve on”. Well, yes, but then again, Composer is not trying to replace APIs and Anypoint Platform; it’s trying to resolve problems of basic connections between systems usable by organisations and departments with little coding/integration capability.

Most MuleSoft documentation shows how Composer sits along the Anypoint Platform (and RPA). Additionally, due to its visible data mapping user interface, it offers quick and agile development for mapping of source to target application fields, the sort of documentation developed in spreadsheets for APIs.

2. So you can’t extract the integration into an application or component to deploy on the Anypoint Platform?

Not at this time. Although this could change, for example, by mid-2022, users couldn’t share flows.

Currently, all flows are deployed under an organisation. So all users of that organisation can see all flows. (The functionality to share flows was added towards the end of 2022). It also has no concept of environments. Hence, we’ve taken to naming the flow to relate to:

  • Environment
  • Enterprise Functionality
  • Source
  • Target
  • Flow Functionality
  • Version

If you develop a number of flows, this will help in searching and managing deployment.

3. Can’t CI/CD Scripts manage this?

As of early 2023…. No capability to deploy the flow via scripting.

4. So you can get Composer to update multiple applications from a master data source, like publish/subscribe?

Yes, but the design here is critical.

It is possible to create a flow that recognises an event and then updates many applications simultaneously. However, given Composer’s lack of retry and failure notification, this design could easily become an idempotent nightmare. If you consider a publish/subscribe solution, there can be many listeners to one source. Hence, creating a flow for each application update (and entity creation) is more robust. That way, if there is a failure to connect to the target application, message replay and data repair is limited to that application alone.

Additionally, logs are not very detailed nor extractable (again, as of early 2023), although you can set up an email to get failure notifications. So you don’t want to have to debug a large number of message failures daily. So this leads to a practice of making sure the level of messaging shouldn’t be too complex or have high daily volumes.

Speaking to some of the MuleSoft community, their view is that Composer is an integration tool directed towards non-critical flows. Although, they also admitted some clients do use it for critical flows, as they have built up their capability and knowledge of the tool. (As mentioned earlier, it can be a quick and agile solution for a tactical point-point integration)

So if an organisation doesn’t have an IT development function, needs some basic start-up integrations with some of the market-leading enterprise applications, or has some sound systems knowledge and a can-do point of view; it would do them no harm to review MuleSoft Composer’s capabilities.


In this blog “4 Key Takeaways from Developing Solutions Using Composer” we have defined and answered some of the MuleSoft community questions around MuleSoft Composer. We have also discussed some of the good practices we have learnt from implementing Composer-based solutions. 

There is no doubt that as Composer develops and is used by more businesses, additional questions will be asked. When this happens and new recommended good practices are developed we will let you know in an updated blog.

If you need more support on MuleSoft Composer, please reach out to us at Devoteam S Platform.