The end is near! No, not the end of the world as we know it, but the end of the year 2024, with a whole bunch of updates, changes, new features and functions in the Appian platform.

In this post, I want to focus on a few specific changes I spent some time on investigating. As with each new Appian version, I am looking for the impact on decision-making. Specifically, this is:

• Architecture: New or updated components that I can use to replace or enhance existing components.
• Solution Design: New features or enhancements that allow me to do specific things in a different or entirely new way.
• Design Patterns: Changes making me reconsider my library of design or implementation patterns.

I usually contact the product development teams at Appian to get more detailed information about their decision-making process and their idea of what we developers will make of it. A huge praise and thank you to the Appian engineers!

Wonders of Autoscale

As I’ve been exploring Appian’s features, one thing that caught my attention was autoscaling. It’s a capability that allows you to dynamically adjust process execution capacity based on demand, which can be a huge game-changer for high-volume processes.

I am looking forward to a future use case in which we might have to deal with starting well over 1 million process instances per hour. I will write a post sharing my experience, once this is in production.

What is Autoscale?

In simple terms, autoscale enables your system to scale up or down automatically as needed. This means that if there’s a sudden surge in activity, the system will automatically increase its processing power to handle it. Conversely, when things slow down, it’ll scale back down to conserve resources.

I was curious about how this works and what kind of scenarios would benefit from autoscaling. It turns out that it’s particularly useful for processes with high throughput requirements, such as:

• Routing new work requests to the right team or system
• Validating data and applying organization rules
• Orchestration of external resources through a central workflow
• Consuming high-volume incoming messages

These types of processes can be critical to your business operations, but they often require significant processing power. Autoscaling takes care of that for you, ensuring that your system can always handle the demand.

Keep in mind that this feature does not come for free! You need to update certain process models to make use of autoscale, and you will have to discuss additional pricing with your Appian representative.

When To Use Autoscale?

While autoscaling sounds like a no-brainer, it’s not necessarily suitable for every process. If you have processes with human interaction or other factors at play, they might not benefit from autoscaling. It’s essential to assess each use case and determine whether autoscaling would be beneficial.

How To Enable Autoscale?

Enabling autoscale is relatively straightforward:

1. Open the process model you want to run with autoscale.
2. From the process modeller menu, select File > Properties.
3. Select the Autoscale checkbox in the process’s properties.
4. Save and publish the updated process.

Once enabled, the palette will adjust to show supported nodes for autoscaled process models.

Supported Nodes

The following nodes are supported in autoscaled process models:

• Activities: Script Task
• Events: End Event, Start Event
• Gateways: AND, Complex, OR, XOR
• Data Services: Write Records, Write to Data Store Entity, Write to Multiple Data Store Entities
• Integration & APIs: Call Integration
• Process Management: Start Process

Chaining & StartProcess

The all new Autoscale feature also has impact on how certain existing function work. I experienced this in the following scenario.

I was working on a user interface to generate a dynamic PDF. Take a look at this related post here. My process model looked like this before we had our Appian environment updated from 24.3 to 24.4. I use activity chaining to control at which point the process evaluation returns, and defer the file deletion in the background.

To start that process in the background and retrieve the ID of the generated document, I used the following code snippet:

After the update, Appian changed the name of the function to this:

a!startProcess_24r3(

This way, Appian indicates that there is a new version available, but the existing code keeps working as it is. This is fantastic, but I wanted to test what the new version is doing. Changing it to:

a!startProcess(

still starts the process in the background, but it takes very long, and I could not retrieve the document ID. Hm … there is a new parameter

• isSynchronous: When true, onSuccess is not evaluated until the child process is complete. If the process is not completed within 30 seconds, onIncomplete is triggered. The child process will continue to run and can complete beyond the timeout.

OK, that makes sense, but why does my process not complete. The Appian engineers pointed out, that the concept of activity was used in situations it was never made for. Find my other post on activity chaining here (I will update it as well).

So I need to adjust my design pattern. Turns out, that when I start a process with isSynchronous set to true, it is executed with high priority, similar to when using chaining. But it waits till the process is completed or times out after 30 seconds. Find this explained in the documentation here.

So I adjusted my process design by decoupling the deferred activities into a separate asynchronous sub process. Then my main process can proceed to the end node, and I finally get my precious document ID.

This is quite a significant change!

The other affected design pattern is when you start a process from a Web API. Earlier, we used chaining to define when the control flow returned back to the a!startProcess() call. Now we have to use a pattern like the above to make this work.

Another important issue to keep in mind is, that any existing process model which uses the “Start Process” smart service just keeps working without any change. But when you add a new “Start Process” node to that model, the new node will behave different from the old one! Without any clear visual indication!

UI Data Stores

The Data Store Design UI got an update. Goodbye forever and all the best for the old.

BTW, Data Stores are still the only way to make Appian automatically manage your database schema at deployment time. Dear Appian engineer who is reading these lines, we really need this in Records! Your job is about making my job easier. Manually maintaining DDL scripts is such a huge pain!

The End

That was 2024. I am excited about some cool updates coming to the Appian platform and the Appian Community in ’25.

If you already have any real-life experience with Appian Autoscale, let me know.

Keep rockin’, and see you next year!