Transform Manufacturing Processes with PLM

This blog is about the 'Workflow: The Ultimate Springboard for Intelligent Automation' video, presented by Daniel Dam from Mendix. You can watch the video here.

But before we take a closer look at this new language, let’s explore how it originated.

Bridging the gap between business and IT

Mendix has always been about bridging the gap between business and IT. Around 2005, the founders realized that both sides of the app development process were speaking a different language. In order to bridge this gap, they created a common language we now know as Mendix.

Mendix’s original image from 2005, explaining how model-driven app development bridges the gap between business and IT

This new common language made it much easier for developers to involve the business in the development process. Developers were no longer writing code that couldn’t be read by somebody from the business side who didn’t have a background in writing code. Instead, their work became interpretable through visual and model-driven development. At the same time, developers were able to develop and deploy more rapidly. All of this allowed the business to provide feedback early on in the process, when adjustments could still be made. As a result, developers gained a deeper understanding of the business process and what needed to be built throughout the building process.

A new visual language

However, there was still part of the gap that wasn’t being bridged by this new common language. With Mendix, developers were able to speak in a common language with the business regarding the individual parts of the business process (data, logic, UI, and security). But the overall business process wasn’t covered by the Mendix platform. That’s all changing with the introduction of a new additional visual language called Mendix Workflow.

With Workflow, Mendix didn’t just introduce a new common language. They empowered the business by giving them more ownership and control over their role as citizen developer. Because with Workflow, they are now equipped to build process solutions, digitize processes, and drive intelligent business automation.

How does it work?

We know that Mendix is all about ease of use, and you should be able to deploy your new app with just a few clicks. Of course this also applies to Workflows. When you create a new workflow, you can either start from scratch or use a template that you can then modify to suit your process. Mendix has already created a number of templates for you to choose from and more are available in the Marketplace (previously known as the Mendix App Store).

You can then edit your Workflow in either Mendix Studio (if you are a citizen developer) or Mendix Studio Pro (if you are a low-code developer).

Workflow in Mendix Studio

A Workflow can consist of User Tasks that are linked to roles (e.g. hand out laptop to new employee or order new lease car) and System Tasks (e.g. send e-mail or message, call other Workflows or Microflows). All of the tasks can be modified with just a few clicks. You can make Workflows smart by adding logic with Microflows, for example to calculate decisions.

Workflow in Mendix Studio Pro

You have the ability to trigger other Workflows from within your Workflow. To help the end-user oversee all of their tasks in different Workflows, Mendix added the Tasks Overview that you can optionally integrate to any app. This will give the user a drop-down menu in the top right corner, which they can use to directly navigate to tasks or perform task actions with a simple click from the overview.

Every Workflow has a Workflow Admin Center with a Workflow Dashboard. As a Workflow owner, you want to have insight in its performance, which is exactly what the dashboard can provide.

On the dashboard, you can see all the metrics at either Workflow or task level and type, for example, to see which tasks are delaying your process.

And of course, the newly unveiled Mendix Data Hub is also available in Mendix Workflow to maintain governance and reuse data across apps and workflows.

I encourage you to watch Daniel Dam’s presentation from Mendix World 2020 for a demo of this cool new language, to see how it empowers citizen developers and closes the gap between business and IT. 

At CLEVR, we believe low code isn’t just about speed anymore. It’s about delivering strategic value as it is fast, flexible, and effortlessly connects with both modern and legacy systems. Simply put, low code has all the elements you need to build software that’s not just important but absolutely critical to your business.

From Prototypes to the Core of Your Business 

Low code has come a long way. What started as a way to quickly prototype and build internal tools, has grown into a mature development approach. Today’s low-code platforms are robust enough to handle the complexity, scale, and security requirements of business-critical systems. With the right approach and mindset, it’s not only possible but proven to work.

But before we go deeper, let's lay the groundwork of what we actually mean by “business-critical software”.

What Is Business-Critical Software? 

Business-critical software refers to the systems that your organization simply cannot function without. These are the backbone of your operations and if they go down, the consequences are immediate and serious:

• Operational disruptions
• Economic loss
• Reputational damage
• Regulatory or legal risks 

Think about order processing, financial operations, supply chain planning, customer service—functions at the heart of your business. These are not just systems of convenience; they are essential.

Why Low Code Is the Smart Choice for Scalability and Simplicity

By 2025, Gartner predicts that 75% of all new enterprise applications will be built using low code technologies. That is no coincidence. 

With a growing need for faster innovation and a shortage of IT talent, low code serves as an accelerator. It enables businesses to develop software faster, iterate more quickly, and fosters better collaboration between IT and business teams.

At CLEVR, we have been working with low code for over two decades. We have seen it grow from a way to solve small-scale challenges to a strategy for managing systems that handle thousands of daily transactions, ensure compliance, and support critical customer-facing operations. 

However, building business-critical systems with low code is more than just plug-and-play. Success depends on doing it right.

The CLEVR Way: Building in Balance 

To meet these challenges, we have developed a proven methodology known as The CLEVR Way. This approach combines the speed and flexibility of low code with the discipline required for enterprise-grade applications.

The CLEVR Way focuses on creating the right balance between key aspects of your business:

• Speed & Control
• Agility & Scalability
• Flexibility & Security 

This is a collaborative process to ensure shared responsibility, which is especially crucial in Agile environments. From day one, we work closely with your team to define clear requirements and align them with your architecture.

What You Gain 

When implemented correctly, low code delivers significant advantages for business-critical systems:

• Faster Time to Market: New features and updates go live in days, not months, thereby enabling you to react quickly to change, even in high-impact systems.
• Lower Build & Run Costs: With visual development and reusable components, you reduce both development time and maintenance overhead.
• Seamless Integration: Modern low code platforms are built API-first and integrate smoothly with everything from legacy systems to modern cloud data lakes like Snowflake. We often pair low code with iPaaS integration layers for maximum impact.
• Better Business-IT Collaboration: Visual development bridges the gap between business and IT, which is critical when building complex, business-critical applications that demand deep mutual understanding.
• Cloud-Native by Default: With cloud-native platforms like Mendix, a globally recognized leader in low-code and trusted platform by major enterprises and corporations worldwide, you get unmatched flexibility in deployment, hosting, scalability (both vertical and horizontal), and high availability. All critical for handling business-critical workloads. 

At CLEVR We Leverage an Architecture-First Approach

Want to make low code a strategic pillar in your IT architecture? At CLEVR, we rely on two robust models to guide this process:

• Gartner’s BOAT Model: Positions low code as a front-end and logic layer, which is ideal for driving innovation while keeping your core systems intact.
• Gartner’s Pace Layered Model: An established framework that separates your IT landscape into systems of record, differentiation, and innovation. Low code excels in the top two layers, where speed and adaptability matter most. 

By thinking “architecture-first,” you ensure low code isn’t just a tool but a long-term enabler of innovation.

Pitfalls to Avoid

Low code is powerful, but it’s not immune to missteps. A common mistake for example? MVPs that quietly evolve into business-critical systems without the right governance in place. 

To avoid this, here are some lessons from the field: 

• Conduct a Business Impact Analysis (BIA): Understand the risks of downtime and define recovery strategies. 
• Use an Application Portfolio Matrix: Assess business value vs. technical health, and take action where needed.
• Don’t Ignore Non-Functionals: Performance, security, maintainability, they all matter just as much as features.
• Think Long-Term: Our solution architects are embedded in every project to ensure alignment with your target architecture.
• Document Thoughtfully: Agile doesn’t mean “no documentation.” For critical systems, clear documentation is essential. 

The Bottom Line 

Low code is no longer just a fast track to MVPs and small business applications. It’s a fully matured enterprise-grade technology. With the right architecture, governance, and collaboration model, you get the best of both worlds: agility and stability. 

At CLEVR, we help organizations implement low code as a strategic enabler, rather than a temporary fix. Together, we make it a fundamental part of a future-ready IT architecture.

Want to Learn More? 

We are hosting a series of breakfast sessions where our experts (and customers) can dive deeper into what it really takes to build critical systems with low code. 

Interested? Let’s talk. 
Reach out directly to svddeijssel@clevr.com or call +31 6 52601544. 

FAQs

{% module_block module "widget_1007a03c-c537-4fdf-8a88-df29d95643ba" %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "colors" is_json="true" %}{% raw %}{"background":"light-blue","text":"darker-blue"}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "faq" is_json="true" %}{% raw %}[{"content":"Yes. Mendix offers the speed of low-code development combined with enterprise-grade performance, scalability, and reliability—making it ideal for business-critical use.","title":"Is Mendix suitable for business-critical applications?"},{"content":"Mendix supports microservices, API-first, and event-driven architectures with built-in tools for integration, orchestration, and modular deployment.","title":"How does Mendix fit into modern IT architectures like microservices or API-first?"},{"content":"Absolutely. Mendix connects seamlessly with systems like SAP, Salesforce, and Ortec using REST, OData, and events—enabling fast innovation without disrupting the core.","title":"Can Mendix integrate with existing ERP and CRM systems?"}]{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"colors":"group","faq":"group","padding":"group","squeeze":"choice","squeeze_position":"choice","structured":"boolean"}{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}61963180038{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"/clevr/modules/clevr_faq"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}[]{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "squeeze" is_json="true" %}{% raw %}"s"{% endraw %}{% end_module_attribute %}{% module_attribute "structured" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Since actions are the main way of using many app store modules, it is worth investing some time and thought in designing good actions. Here are eleven best practices that I have for anyone who is writing a java(script) action, either for use in a project or as a part of a reusable module.

1. Use descriptive parameter names and suffix them with an underscore

The name of a parameter should be descriptive and not redundant. That is general advice for naming that also holds true here. So avoid names like object, parameter, data. Keep in mind that action parameters are not only used in Mendix when the action is invoked, but also in java(script) code as variable names. This causes a slight problem when the parameter name is a reserved word in the respective language e.g. Object. To deal with this, Mendix would suffix the variable name in code with Parameter1 etc. This has been reworked in newer Mendix versions, which actually makes the problem worse. Now the same action code might work fine on an older Mendix version and fail to compile on a newer Mx version because of the different ways variable names are generated.

By using an underscore suffix all conflicts with reserved words that I am aware of can be eliminated and is actually not even visible when the action is invoked, as seen in the screenshot below. Perfect!

2. Add a new action instead of making signature changes.

We have all been there. Even the most well though-out action will need to change. Some of those changes will inevitably involve changing the signature, for example because a new parameter is added or a return type is changed. This is very disruptive, since all respective action calls throughout the project need to be updated.

The old action should internally call the new one and pass a default value for the new parameters or ignore a return value if one was added. Make sure to give both actions a logical name, perhaps the old action should include the word deprecated somewhere. A supplemental practice to avoid too many signature changes is described next.

3. Bundle flags, enums and integer settings into a single "Options" object.

Many times an action will have several flags or different settings that can be tweaked and therefore need to be exposed somehow. It is best to bundle all of these as a single object parameter, often called Options, Settings or Configuration.

By using an "Options" object multiple problems can be tackled at once: 1) adding a new setting does not change the signature; 2) default values can be defined in the object and do not pollute the constant space; 3) documentation for each flag has a clear place to live without overwhelming the action dialog; 4) the action parameter list can be shorter making it faster and cleaner to invoke the action (remember each parameter has to be explicitly set).

An example of an "Options" object from the parallel execute app store module.

4. Always use a facade instead of calling third-party libraries directly.

This one is for all who use third party dependencies in the form of jar files or javascript modules. I wrote a separate detailed blog post with the best practice for this. By using a facade we avoid hard coupling and make it possible to swap the library without too much hassle. Also, it is best to use a language specific dependency management and build tool such as maven or gradle for java, and npm or webpack for javascript. These tools offer easy management of transitive dependencies, test integration into the build process and packaging for the desired platform.

5. Guide the user in constructing object hierarchies with a builder pattern

In some cases arguments for an action are not a simple number or an object with a few parameters. Instead, an entire hierarchy of objects is needed, and it has to be associated in a specific way that is expected by the action. This is impossible to enforce at design time, so a clever way is required to guide the user in constructing the right hierarchy and setting the right associations.

In the case of medium-sized hierarchies, i.e. one or two associations, I prefer to use a builder pattern to help the user prepare the data. The builder pattern allows complex hierarchies to be built with simple steps, one step at a time. Additionally, each step is constrained using types often only obtainable from other steps. In an ideal world, it would be possible to entirely prevent manual instantiation of some builder objects, thus forcing the user to create them using an action.

Example of builder pattern used in my "Web push notifications" module. In step1 a notification object is constructed using a java action. Then in step2 a NotificationAction object is created and associated to a Notification, but instead of doing this directly again a java action is used which requires a Notification object as a parameter. This makes it impossible to confuse the steps order and call step2 before step1 or to forget setting the association.

6. Use the most specific and constraining types as possible.

This is another general advice, that also applies to actions and is tightly related to the previous best practice. Instead of strings "Yes" or "No" use boolean. Use enums and dates in place of strings where applicable. Avoid overloading nulls or other special values to convey information, instead use specific types or enums for that. For example, if the response is an error message or null (terrible idea btw, see 11) use an object with a boolean "HasError" and an error message instead.

7. Only use code for things that can not be done in Mendix natively.

If something can be done in Mendix then do it in Mendix. Especially for retrieves and/or changing objects. It is much easier and safer to call a flow from the middle of the action to do a retrieve natively in Mendix than to construct the XPath and retrieve with code.

When changing object attributes, remember that renaming the attribute, does not automatically rename existing calls to getter/setter methods on the respective proxy. So again, only use code when there is no alternative to doing the same natively in Mendix.

8. Do not add unnecessary coupling to Mendix runtime and core methods.

Avoid coupling code with Mendix APIs, especially for java actions. Mendix often makes changes to the runtime and core methods, just see this huge list in Mendix 8 version. So to avoid headaches, do not rely on Mendix runtime libraries or core methods unless absolutely necessary. It is clear that some coupling is unavoidable the goal here is to limit this to the absolute minimum.

If you follow the other best practices this one should come naturally. As an added benefit, if at one point you decide to move this part out of Mendix and into a separate server then having fewer dependencies will make it easier to migrate that part of the functionality.

9. Validate the number and types of parameters for microflow parameters.

This only applies when using microflow as parameters. Unfortunately, Mendix still does not allow to restrict the parameter number and types when used in an action. Until that is implemented the next best thing is to check the input and output types at run time. This is not trivial, please check the parallel execute module for a good implementation which also covers inheritance.

10. Use json as intermediary for communicating with actions.

Builder pattern was already mentioned as a way of dealing with medium-sized object hierarchies. But what about large object hierarchies? In this case it is best to resort to json. This gives users complete freedom to map their own entity diagram to/from json using an export/import mapping. Mappings are natively supported in Mendix which means they come with type safety and allow for easy renaming of entities, associations and attributes. This in contrast to code where any such rename would cause a compilation error.

To take it to the next level I suggest using JSON schema to validate the incoming/outgoing json. A free bonus that you get by using json is that it makes actions easier to test. No need to build an object hierarchy for every test case, simply paste a test json.

11. Let exceptions propagate instead of swallowing them.

If an exception occurs inside code, best to let it propagate to Mendix. Then the caller of the action can decide on how to best handle it. There is rarely a good reason to swallow exceptions.

Sometimes it might be useful to re-throw an exception with a simpler error message and log the actual message on a level other than error. For example, "NumberFormatException in line 192*"* is much less informative compared to "Amount is not a valid number".

''I hope you enjoyed reading this post and that it helps you design better Mendix code actions!''