A constant is a literal value that can be called from any expression, so it can be reused across multiple objects throughout the system.
Each time you modify and save a constant, a new version is created. All expressions that use the constant use the latest version. All versions are accessible to designers who can view the constant, and a constant can be reverted back to a previous version at any time.
Each constant has the following properties:
|Name||The name that is used when executing the constant. This property is case-insensitive, but we recommend that you follow the recommended naming standard. Certain constant names are reserved for system use.|
|Description||Supplemental information about the constant that is displayed in the inline help within the expression editor and the application contents grid.|
|Type||The type of the constant.|
|Array||Constants can either be a single value or an array of values.|
|Value||The value that is returned when the constant is called.|
|Environment Specific||When enabled, the constant's value is not updated on import unless set via an import customization file. This is to prevent unintentional changes to an environment's value for this constant.
Set constants to environment specific when their values are different based on the environment they are on so that their values can be preconfigured and won't need to be manually updated after an import, for example, a web service endpoint.
Only constants that are of a primitive type or the Email Address type can be set to environment specific.
|Save In||The folder that the constant is saved into.|
The following names are reserved for process report metrics, and must not be used for custom constants.
Constants of deprecated types cannot be created except by duplicating a constant of that type.
To create a constant:
Configure the constant properties.
Constants are called using the
cons! domain, as shown below.
Opening a constant displays its properties in a dialog for editing.
The value of a constant can be changed either from this dialog or from within a process using the Update Constant Smart Service or the Increment Constant Smart Service. When you save a new version of a constant, the latest version is available immediately. This means that any object that uses this constant immediately uses the new version. It is therefore important to carefully consider the impact on running processes when changing constant values. Appian recommends that you follow these best practices to facilitate the change management of constants:
Each time you modify and save a constant, a new version is created. All objects that use the constant will use the latest version. All versions are accessible to designers who can view the constant, and a constant can be reverted back to a previous version at any time.
For information on how to manage object versions, see Managing Object Versions.
Users with Administrator permission to this object or rule folder can move it to another folder:
NOTE: Any objects that are configured to inherit the security of the parent folder assume the security rights of the target folder.
Deleting a constant prevents users from further viewing or editing it. However, the last version of the constant is still available to be used in processes, record views, and reports.
Constants can be deleted by users with Administrator rights to it. Appian does not recommend deleting constants that are in use because the constant can no longer be exported.
To delete a constant:
System administrators have the ability to delete constants (and other objects) in bulk by selecting them and clicking Delete in the toolbar.
Renaming a constant will automatically update references to it in all objects. To rename a constant:
Learn more on Renaming Design Objects.
Any user can access the value of any constant that is referenced by an interface or process they have permissions to.
A user must have at least Editor permissions to increment or update a constant's value via a smart service in a process model.
The security role map of a constant controls which developers can see or modify it and its properties. By default, constants inherit the security of the folder that they are saved in. However, after creating the constant, you can disable that inheritance and modify the constant's security. See Editing Object Security to modify a constant's security.
The following table outlines the actions that can be completed for each permission level in a constant's security role map:
|Evaluate the constant||Yes||Yes||Yes||Yes|
|View the constant definition||Yes||Yes||Yes||No|
|Duplicate the constant||Yes||Yes||Yes||No|
|Update the constant definition*||Yes||Yes||No||No|
|View the security||Yes||Yes||No||No|
|Rename the constant||Yes||Yes||No||No|
|Delete the constant||Yes||No||No||No|
|Update the security||Yes||No||No||No|
*Constant values can be edited via either the increment constant smart service or update constant smart service in process models. Users must have Editor permissions to the constant to execute these smart services successfully.
When a constant is used in an expression, the value that is returned is the same regardless of which user evaluates the expression. However, functions that use the value may fail based on the user's permission. For example, if the constant value is a group that the user does not have permission to see, the constant returns the value successfully but using the
group() function returns an error.
See the User Contexts for Expressions page for more information on what user context is used when evaluating expressions in process.
Developers must have Viewer permissions to a constant to duplicate it. From any view within an application's context, a developer select a constant and duplicate it using the toolbar option to launch the duplication dialog. The newly created object will be added to the current application. This toolbar option is only available for single object selections from the grid.
On This Page