Watching the webinar, requesting the update, analyzing the release notes, trying to find changes in the documentation. These are the four steps I do for each new version. Just like you do.

Then I rework our guidelines for UX, UI and coding, and adjust our review procedures. And I prepare presentations to share the news, and the impact on our way of working, with all my Appian team members.

In the following, the most important changes and how we plan to use them.

Asynchronous UI

Wow, this was completely unexpected. I can now display all the readily available information to the user, and update certain sections as the required data, pulled from a slow API, finally arrives.

I consider low latency data querying strategies a high priority. Using synced records, de-normalising data, preparing data at write-time, or even running stored procedures in the background.

And then, there is this API which we cannot sync and cannot adjust to our specific needs. And it takes a full second to return the data. With async loading local variables, we can save our users from a bad UX.

What a great feature! Thank you 😁

Transparency

Let’s start with an example.

Here I use a billboard layout and a full overlay with style “NONE”. The content of the overlay is a list of red card layouts with decreasing transparency.

The syntax to use transparency is simple. Appian added support for the alpha channel for all parameters accepting a color hex code. The color red “#ff0000” with a 50% transparency becomes “#ff000080“.

Color hex codes are made of 3-4 hexadecimal numbers with values from 00-ff. These numbers represent the colors red, green and blue, and the transparency is the fourth one.

Wizard Sidebar Layout

First, the example.

Now, why is this special? When combining a wizard layout with a sidebar template, the wizard step become integrated into the sidebar. Automatically! The just revamped form layout becomes such a great tool to achieve an even better UX.

We consider this style to be our new go-to option.

Auto-Generated Objects

Software evolved quite a bit from the old days of Microsoft Clippy.

With the raise of LLMs, everybody is talking about AI, and we try to find ways to add AI to our toolbox. Generating code is the new normal for all high-code developers. And what about us low-coders?

In my daily work, I spend most of my time thinking about business aspects, process optimisation, functional requirements, and user interactions. Designing and writing code in Appian is just a small part of what I do. And while I do it, I constantly refine my ideas.

With the latest iteration of the Appian Composer, I can dump my requirements into an LLM, and it generates a data model and some basic interfaces and process models!

Does this result in a maintainable, safe and secure application? No, it does not. But why? Because we did not provide all the required information. Hmm… why is that? Because the term development means that nobody knows the exact shape of the final result when starting.

And, I do not comply with the way Composer generates objects. I am missing groups and folders. I think that using rv!record is a huge problem (Partially Populated Records), and using the word “record” for all PVs and RIs is a long-term maintenance problem.

Appian Composer is an outstanding tool I use in specific situations. Just like I do with any other tool. And I am eagerly awaiting future iterations.

File Upload

Up to version 25.2, we had no access to uploaded documents until the user submitted the form ( File Upload in Appian ). The developer community has been begging Appian for more than 15 years to improve this situation.

With 25.3, a whole new era begins, where we have full access to file properties inside the same interface. Appian enhanced the document() function, and the document viewer component displays documents right after upload.

Two things did not change, though. A file upload only becomes permanent after submit, and the save-draft feature still does not support file uploads. Check the linked post above for a solution.

Write & Query Record Behaviour

Writing and querying record has changed many times in the last releases. And this might turn into a dangerous disaster when not taken care of. Some of the changes are quite subtile and easy to overlook.

The great thing about how Appian manages version is that our applications just work, just like before the update. This fact is something I talk to my clients over and over because it reduces the cost of operations and maintenance dramatically.

Any code in expressions is simple to maintain and change, as we can clearly identify old versions. In process models, this is a whole different story. Smart services do not show a clear version indicator. This can result in a process with 5 identical looking nodes, where each node behaves a bit different.

And this is the official way to identify the node version:

… sic …

When we touch a process model, we check node versions and update all nodes to the latest version. This is minimal effort, but at least, we avoid having a mix of versions.

To Appian, please make it easier to identify smart service versions in the process modeller!

Missing Pieces

• Still no automatic DB table management at deployment time.
• The auto-complete menu in the expression editor automatically selects an option when it pops up under the mouse cursor. This drives my crazy!
• When I edit a translation string, the input field looses focus after the first key press.
• In the expression editor, when hitting CTRL/CMD + I to create a new rule input, the input focus is NOT in the name field. Please either remove the keyboard shortcut, or get the input focus into that field.
• 64Bit Integers and Numbers

Final Words

Appian delivers another great version. Just a few years ago, we only had Tempo, two columns, no colors, no translations, and no records.

I truly have to take my hat off to you, the Appian Product Engineering Teams. Thank you so much for your dedication!