Use Composer to Build on Demand

Composer is available directly in the Build view for on-demand requests. You can create or modify design objects whenever you need to, without following a pre-planned set of user stories. This workflow is ideal when you want to make quick changes to an existing application, add individual objects, or explore an idea without committing to a full planning cycle.

You can also use Composer in the Build view to build with user stories from the Board tab, or directly within an interface object. This page focuses on the on-demand workflow from the Build view.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

When to build on demand with Composer

From the Build view, you can prompt Composer to create or modify design objects at any time. If you created an application plan, Composer reads its full context—including existing objects, their fields, and their relationships—to inform its work.

On-demand requests are useful when you need to make changes outside the scope of a user story, when you're working on an application that wasn't set up with Composer's planning workflow, or when you want to quickly explore an idea before committing to a full plan.

For the full list of supported design objects and operations, see How Composer Works.

Chat with Composer on demand

The Composer chat pane is open by default in the Build view. Enter a prompt describing what you want to build or change, and Composer gets to work. Use the dropdown in the chat pane to select Standard or Fast mode before you start. See Composer modes for guidance on when to use each.

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.

To make an on-demand request:

1. In your application, go to the Build view.

2. In the Composer chat, describe what you want to build. For example:

   1
    Create an Employee record type with fields for name, department, and start date.
   

3. For requests that involve multiple objects or multiple actions, Composer proposes a task plan for your review. Verify the operations and target objects match your intent, then approve the plan to begin execution. For single-object requests, Composer executes immediately.
4. After execution, review the created or modified objects in the Build view.

Example prompts from the Build view

The Build view is the best starting point when your task isn't scoped to a single object you already have open. For example, when you need to create new objects, coordinate changes across multiple objects, or explore a user story that may touch several parts of your application.

The following prompts show requests that work well from the Build view:

Goal	Example prompt
Create a record type	Create an Employee record type with fields for name, email, department, and hire date.
Create an interface	Build an interface that shows a grid of open cases with filters for status and priority.
Multi-object task	Create a record action that lets users submit a new support case. Include the process model, interface, and record action configuration.
Delegate a user story	As a manager, I want to approve time-off requests so my team's schedules stay accurate.
Modify an existing object	Add a status field to the Project record type and update the Project Summary interface to display it.

For prompting strategies that produce better results, see Composer Best Practices.

Review changes from Composer

After Composer completes your request, review the design objects it created or modified in the Build view of your application. For modified objects, compare object versions to verify the changes match your intent.

Composer is non-deterministic and can produce different results for the same prompt. Review changes each time you make a request.

If the result doesn't match your intent, ask for adjustments. You don't 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