Manage Expression Rules with Composer

This page explains how to use Composer to create, modify, and test expression rules.

Where to use Composer for expression rules

You can ask Composer to create and update expression rules from the Build view or from AI mode in an interface object.

Composer uses your permissions. If you cannot create or edit an object, Composer cannot do it for you. Composer follows the same object-level security as manual edits.

What Composer can do with expression rules

Composer can perform the following operations on expression rules:

• Generate expressions: Describe the logic you need. Composer writes a valid expression using Appian functions.
• Modify existing expressions: Ask Composer to refactor, optimize, or extend an existing expression rule.
• Query data: Use a!queryRecordType() with filters, sorting, and paging.
• Aggregate data: Add counts, averages, and groupings to expressions.
• Build business logic: Create conditional logic with null handling and edge cases.
• Calculate dates and times: Handle durations, due dates, and time-based metrics.
• Check permissions: Add group membership and user comparison logic.
• Transform lists: Build a!forEach() loops to reshape arrays.
• Generate test cases: Create test cases for the expression rule you are editing.

Example prompts for expression rules

The following prompts show requests that work well when asking Composer to build expression rules:

Goal	Example prompt
Calculate a duration	Calculate how many days until a membership expires and return a color code based on the result.
Query with filters	Query the Customer record type filtered by status and sorted by creation date, with pagination.
Check permissions	Write an expression rule that checks if the current user is a member of the Managers group.
Handle null values	Create an expression rule that returns a default value when the input is empty.
Generate tests	Generate test cases for the calculateDaysRemaining expression rule, including edge cases for null inputs.

How Composer uses expression rule context

When you ask Composer to work with an expression rule, Composer reads the following context from your app to build accurate expression rules:

• Record types: Record types, their fields, and relationships.
• Existing rules: Expression rules and their definitions.
• Rule inputs: Rule inputs and their data types.
• Test cases: Existing test cases on the target rule.
• Related objects: Constants, connected systems, and other referenced design objects.

Composer uses this context to write expressions that reference the correct record types, fields, and rule input names.

Review and apply expression rule changes

After Composer creates or modifies an expression rule, review the changes in the Build view of your application. For modified expression rules, compare object versions to verify the changes match your intent.

If the generated expression does not match your intent, ask Composer to adjust the logic. You do not need to repeat your original request—Composer retains the conversation context.

All Composer changes go through Appian's versioning system. You can undo them with the same version history tools you use for manual edits. Each update creates a new object version, so you can compare diffs and roll back.

The developer owns the outcome of all Composer changes. Treat Composer output the same way you would treat any other change you make: review it, test it, and take responsibility for it.

Relationship to other Composer entry points

Composer has the same full application context from both the Build view and an interface object. From an interface object, you can use Composer to update the interface you're editing. Because the same conversation persists across objects, always specify the interface name in your prompt to ensure Composer applies changes to the correct interface.

Regardless of where you start, you can ask Composer to create or modify any design object. For example, ask it to create a record type and then build an expression rule that queries it.

Feedback