Reusing Interfaces


Interfaces are an important part of Appian applications and with the right interface, you can deploy multiple applications with a consistent look and feel. This page discusses the concepts related to reusing interfaces throughout your Appian applications and how they can make you applications more efficient.

An interface returns one or more components to display on a record view, Tempo report, or process form. This is the primary object that designers use to show user interfaces to application users.

For more information about Interface properties, see Interface Object.

For functional examples of different design patterns, see the Interface Recipes page. These examples will help you learn key interface concepts and can be used as a starting point for your implementation.

Interfaces as Rules

When working with Interfaces, think of them as any other expression rule. Interfaces are versatile and can be used in many places throughout Appian. For example, one interface can be called in a process, record type, and also in other interfaces. To call an interface, simply use the rule! prefix.

Interfaces are defined using expressions, which enable dynamic behavior and reuse of common logic and components across multiple objects throughout the system. They are called and evaluated in the same way as expression rules or query rules.


Part of the advantage of creating Interfaces and Expressions is that you can reuse these objects whenever you need them. Reusing interfaces reduces redundant expressions and helps you easily maintain application objects. Reusing interfaces also helps you create dynamic applications. You can make changes to one interface and see the changes reflected immediately in all other objects calling that interface.



Creating Reusable Custom Components

When you create reusable custom components, you create a more efficient Interface as well as make your Interface more readable.

When you create generic rules that wrap components, such as a custom dollarField component, you need a rule input for the value parameter and a different rule input for the saveInto parameter.

The rule input that maps to the saveInto parameter of the a!textField() function must be an array of type Save. This setup allows fellow designers to use the a!save() function to modify the user input in the same way as if they were interacting with any other interface component.

Best Practice: As a best practice, we recommend using the same convention established by Appian components and calling your rule inputs value and saveInto. Following this practice will help your fellow designers configure your component correctly.

For example, your dollarField rule definition might look like this:

  label: ri!label,
  instructions: ri!instructions,
  readOnly: ri!readOnly,
  disabled: ri!disabled,
  validations: ri!validations,
  value: if(isnull(ri!value), "", dollar(ri!value)),
  saveInto: a!save(ri!saveInto, todecimal(save!value))

The user's input is passed to the todecimal() function and the result is saved into the designer-configured variable so that the designer only deals with decimal values. The value argument is formatted using the dollar() function.

Using Interfaces with Other Objects

Interfaces can be used with other objects to reduce the amount of code in certain design objects. Interfaces can be used in records, reports, process models, or constants. You can also easily identify whether any errors are caused by your Interface.

For example, Interfaces are can be used for the summary of record views.


Submitting User Inputs to a Process

When a form is used as a process start form, the components on the form can update process variables configured as parameters.

Attempting to save into a process variable that is not a parameter does not cause an error. However, if you find that your process variable is not updating as expected, verify that the Parameter checkbox is selected in the Process Model Properties dialog. Local variables cannot be used to update process variable values.

Similarly, when a form is used as a task form, the components on the form can update node inputs configured on the node. However, process variables cannot be updated from a task form and local variables cannot be used to update node input values.

  • NOTE: Inline task approvals cannot currently be configured for forms.

Start form parameters are available to the form expression in the pv! domain. Task form inputs are available in the ac! domain. For example, a process parameter called "employee" is accessed via pv!employee and a task input with the same name would be accessed via ac!employee. These variables can then be passed as inputs to rules. They should not be accessed directly from within expression rules. As the user interacts with a form, they update these rule inputs, and when the user submits a form, the new values are submitted back to the process engine.

  • NOTE: The values that are submitted to the process engine are the values of the variables at the time of submission, not what is displayed in the interface. See also: Enabling User Interaction

To walk through an example of how to map a variable to a component via a rule input, see also: Process Model Tutorial

When calling an interface, values or variables can be passed to the inputs by position or by keyword, as shown below.

  pr: pv!purchaseRequest,
  items: pv!prItems,
  cancel: pv!cancel