Welcome back to the blog. 80% chances are that you’re an Appian developer and love to explore what is possible on Appian. Appian releases 4 times each year and we’re all excited about all the new features coming out but as part of my work on Appian, I always find myself dreaming of more features.
So here are some Appian features you and I wish existed.
1. Application versioning
How many times have you taken an export of the codebase from the Prod environment just to keep a backup if the deployment goes wrong? I do it every single time and this can be solved by Application versioning. Appian already tracks all the objects and their versions. How about adding an extra version tracking on the app level where you audit which object was on which version before the deployment/import and the ability to revert all the objects back to their original state (state before the deployment) with just a single click.
2. Able to search within the constant values
Appian expression search is a great way to search for the exact words within an expression but sadly it doesn’t work on constant. Implementing this can have its own set of complications like the type of constant but if this was available for text type constants, then it would have been a great way to search for button action constants and also a great way to check for duplicity in the same values shared by multiple constants.
3. Disable the entire interface
While working on restricting a user from working on an interface because someone is already working on it (locking mechanism), all the fields and buttons have to be disabled manually or another workaround is to hide the entire interface and show a warning but how cool would it be to have the Appian’s default disabled functionality that it has when you haven’t accepted a task. Every part of the screen stays disabled until you accept the task, so on the same lines, if this is released as a new attribute to formLayout, headerLayout, etc, then it will save a lot of time and increase the user experience.
4. Ability to see the original name of the node in Process
When a node is added onto the process modeler canvas, and the name is edited, there is no way to identify which smart service it was, other than remembering the icons of the smart services. It becomes even more problematic when the services have almost the same icons. Just adding a new property to the node, which is the original name of the service, which cannot be changed will ease this hassle forever.
5. Portals to be used as embedded interfaces
Portals have been a great addition to Appian’s capabilities and a way for anonymous users to interact with the app but they need their own URL to load.
Appian has a concept of embedded interfaces that allows users to embed the Appian interface into any public website and leverage the low-code designed forms.
Adding a similar functionality to portals where you can embed them into any website will increase its usability.
6. Get document properties before it is uploaded
All of us know that we cannot use document() function on a document that is just uploaded in a file upload field and not actually created on Appian because it is treated as a temporary document. Even though Appian has access to all the details of that document which you can see in the below screenshot, they have restricted the use of document() function only on fully uploaded documents.
Removing this restriction will allow devs to use it for storing the name of the file, showing the user the extension, and accessing other properties for validation and utilization purposes.
Not only this, but it will also allow previewing of the document before it is finally uploaded so the user can check and change the document or even preview the document on the same screen before the form is submitted.
7. Section Link
The feature is about being able to click on a hyperlink and able to navigate to that section on the same screen. Like how we have on websites where clicking on something scrolls the page and takes the user to a certain section. Similarly, something like ‘a!sectionLink()’ which takes the section label or some identifier as input and takes the user to that section on the same page.
This would be helpful when there are dense interfaces or long interfaces having a lot of scrolls. And as portals come into the picture, this can also be very well used on Appian portals as they are expected to have long scrolls.
8. A new height – FIT
A lot of Appian components have a height parameter like paragraphField, cardLayout, gridField, etc. using which you can fit the height of that component but the downside of it is we always find ourselves in a situation where we need more height to fill the entire screen or something that covers the entire height available in its parent. eg. adding a cardLayout() inside another cardLayout() with the height set to TALL. Then the inner card should stretch itself to consume all the available height in the parent.
It would be even more interesting if Appian allows users to input height in pixels or percentages.
9. Ability to define global validations
If you apply validation to a component and it is not visible, then that validation is not invoked. That is how validations are expected to work but it becomes a problem when you are using a multi-pager/stepper form where you only see one page at a time. Now you would like to validate all the validations on the final submit button but Appian will only validate the visible components.
If there was an option in the button layout to override all the visible and not visible validations, then it could ease out a lot of efforts of checking the values of all of those fields manually.
Do you have some features in your mind that you wish existed? Let me know in the comments below and also comment down your favorite feature from the above list. ⌨️💬
Will see you with more interesting stuff in a new blog post. #HappyLowcoding
Appian Space 
Leave a Reply