Function and Component Versions

Overview

This page describes how Appian introduces improvements to functions and Interface Components (collectively referred to as "Function(s)" on this page), while preserving backwards compatibility.

Historically, when we wanted to improve a Function, we would wait until we had enough changes to justify introducing them as an entirely new Function. Starting in Appian 17.2, we introduced the concept of Function versions, where we add a new version of a Function, but leave the old version in place with a slightly modified name.

New Function Vs. New Version

When we add a new Function, instead of improving an old one, we give it a new name. We do this when there is sufficient difference in usage that it would amount to large changes in design. A great example of this is the new a!forEach() Function, which supercedes the capabilities of apply() and a!applyComponents(), and uses a different design pattern.

When we add a new version of a Function, instead of improving the old one, we give it the same name, and change the name of the old Functions. We do this when we want to improve a Function in a way that would not preserve backwards compatibility in all cases, and where we intend for it to take the same place in the Appian paradigm. Otherwise we'd bloat our library of Function options, introducing confusion about when you should use which. The a!toJson() Function is a great example; we have some solid improvements to the Function, but there are a few cases where it's used in a way that would break if we changed the old Function.

How Do I Know If I'm Using an Old Version?

You can tell if the Function you're using is an old version by looking at its name to see if it has a suffix in the format of _XXrX, where the X's represent the last version of Appian where that Function was used.

For example, if you were using the Dashboard Layout in an interface in Appian 17.1, your interface showed it as: a!dashboardLayout. After upgrade to Appian 17.2 or later, if you look at that same interface, you'll see that the name has been changed to a!dashboardLayout_17r1.

  • Before: a!dashboardLayout
  • After: a!dashboardLayout_17r1

Do I Have to Use the New Version?

No. You may continue to use old versions indefinitely.

However, since new versions of Functions often contain desirable improvements to functionality, design simplicity, performance, and stability, you'll likely want to switch at some point.

Changes You'll See In Appian

Old versions of Functions will not appear in type-ahead suggestions.

However, you can continue to use old versions without issue, and when using an old version, the documentation pane will provide information specific to the version of the Function you're using.

Changes You'll See In the Documentation

Old versions of Functions are not used in examples or interface recipes, and are not listed in category lists.

However, all old versions of Functions still have their reference pages available in the documention. You have a number of options for finding that content:

  • Search the docs. For example, just search for: dashboardLayout_17r1 and you should quickly see it in the type-ahead results.
  • Find it in the Appian Functions Page.
  • From the latest version's page, in the section titled "Old Versions." For example: Dashboard Layout.
  • Or from the table below that lists all Functions that have been changed this way.

All Updated Functions as of 18.4

The following table lists all Functions that have older versions, the updates made to that Function, and all associated older versions as links to their reference pages.

Latest Reason for Update Old Versions
Cancel Process Smart Service
a!cancelProcess

This function was updated to handle scenarios where the selected process has already been canceled or completed. Instead of throwing an error in these cases, a new function variable, fv!alreadyClosed, will be set to true and available for use in your logic.

a!cancelProcess_17r3
Create Knowledge Center Smart Service
a!createKnowledgeCenter

The securityLevel has been removed in the Appian 18.1 release. Knowledge center security is managed completely by normal object security.

a!createKnowledgeCenter_17r4
Dashboard Layout
a!dashboardLayout

Replaced firstColumnContents and secondColumnContents with contents. Now supports greater than two-column layout.

a!dashboardLayout_17r1
Document Browser Component
a!documentBrowserFieldColumns

Now supports selection in addition to browsing.

a!documentBrowserFieldColumns_17r3
a!facet() Function
a!facet

Added the allowMultipleSelections parameter, which, by default, allows multiple selection user filters.

a!facet_17r1
File Upload Component
a!fileUploadField

Multiple file upload is now supported directly within the component. This removes the need to generate many individual file upload fields.

a!fileUploadField_17r1
Form Layout
a!formLayout

Replaced firstColumnContents and secondColumnContents with contents. Now supports greater than two-column layout.

a!formLayout_17r1
Paging Grid Image Column Component
a!gridImageColumn

Now supports a style parameter, a separate configuration for thumbnail functionality, and more sizes.

a!gridImageColumn_17r3
a!httpResponse() Function
a!httpResponse

Can now return documents through Web APIs so that other systems can access Appian documents.

a!httpResponse_17r4
Image Component
a!imageField

Now supports a style parameter, a separate configuration for thumbnail functionality, and more sizes.

a!imageField_17r3
a!queryEntity() Function
a!queryEntity

Added the fetchTotalCount parameter, which, by default, avoids running the query that retrieves the total number of rows in the totalCount parameter of the resulting datasubset.

a!queryEntity_18r3
Styled Text
a!richTextItem

New version supports multiple values in the style parameter, as well as custom hex colors.

a!richTextItem_18r1
Section Layout
a!sectionLayout

Replaced firstColumnContents and secondColumnContents with contents. Now supports greater than two-column layout.

a!sectionLayout_17r1
a!toJson() Function
a!toJson

Improved support for datetime values. This removes the need to create a supporting conversion rule.

a!toJson_17r1
FEEDBACK