Composer Best Practices

Follow these practices to get effective, predictable results from Composer whether you're planning your application or building design objects.

Write effective prompts

Composer performs best with focused requests that include specific details. Vague prompts force Composer to make assumptions, which can produce results that don't match your intent.

Structure your prompts to include:

• Action: What you want Composer to do (create, add, modify, remove, suggest).
• Target: Which objects, tabs, or elements are involved, by name.
• Expected outcome: What the result looks like when done correctly.

Less effective	More effective
Update the case form.	Add a status dropdown field to the Case interface that pulls values from the Case Status record type.
Add a date field somewhere.	Add a due date field to the OB Employee Task record type and display it on the OB_EmployeeTaskSummary interface.
Add more steps.	Insert a Manager Approval task after the submission node in the Leave Request process.
What's missing?	Are there any missing personas for a customer support application?

Work incrementally

Work through one request at a time rather than asking for an entire application or plan at once. Incremental requests give you more control over Composer's output and make reviewing changes easier at each step.

Composer understands your context, so each subsequent request builds on what already exists. You don't need to re-explain the full application structure or plan in every prompt.

Review Composer's output

Treat Composer's output as a starting point, not a final solution. Always compare suggestions, generated plans, and design objects against your goals before accepting them.

• If a suggestion doesn't fit, adjust it or remove it entirely.
• If a task plan lists operations you didn't expect, request changes before approving execution.
• If a generated object isn't quite right, ask Composer to adjust—it retains your conversation context.

You always have the final say on what makes it into your application.

Best practices for planning

The following best practices apply when you're working with Composer in the Plan view to define requirements, personas, processes, data models, and screens.

Ask questions across planning areas

Composer remembers your conversation as you move between tabs. You can switch from Stories to Data Model to Process and continue asking questions or making requests without re-explaining your context.

Use this to your advantage:

• After discussing a "Leave Request" requirement in the Stories tab, switch to the Data Model tab and ask What fields should the leave request table include based on what we discussed?
• While reviewing a screen in UX Preview, ask Add an 'isArchived' field to the Case table in the data model and Composer updates the data model directly.

Identify gaps in your plan

Ask Composer to look for missing pieces rather than only reacting to what's already there. For example:

• Are there any missing personas for this type of application?
• What steps in this process could be automated?
• Can you suggest more actions users might take before the review step?

Composer analyzes your plan holistically and can detect incomplete requirements, missing approval nodes, or unaccounted-for personas.

Coordinate with your team

The Plan view doesn't prevent multiple people from editing at the same time, so coordinate with your team to avoid overwriting each other's changes. All updates are automatically saved.

Share Composer-generated plans with key stakeholders—including business users and developers—to gather feedback. This ensures your application is technically feasible and aligned with business requirements.

Plan for session resets

Your conversation with Composer resets when you close or refresh the page. For longer planning sessions, work through your most important questions before stepping away. If you need to resume later, provide a brief summary of where you left off so Composer can pick up the context.

Best practices for building

The following best practices apply when you're using Composer to create or modify design objects, whether you're building with user stories from the Board tab or building on demand from the chat pane.

Inspect design object changes

After Composer completes a task, review the design objects it created or modified. For modified objects, compare object versions to verify changes match your intent. Test interfaces and process models to confirm they behave as expected.

Pay attention to:

• Field names and types: Confirm Composer chose appropriate names and data types.
• Expression logic: Verify that generated expressions handle edge cases such as null values and empty lists.
• Object wiring: Check that references between objects are correct (for example, interfaces referencing the right record type fields).

Review task plans for multi-object requests

When a request involves multiple objects or multiple actions, Composer proposes a task plan before executing. Review the plan to verify:

• The sequence of operations matches your expectations.
• The correct design objects are being created or modified.
• Dependencies are resolved in the right order.

If a step looks incorrect, request changes before approving. Adjusting the plan is faster than undoing completed work. For single-object requests, Composer executes immediately without a plan.

Use Composer for repetitive work

Composer provides the most value for repetitive, mechanical tasks:

• Object wiring: Connecting design objects and resolving dependencies.
• Boilerplate configuration: Creating standard configurations across multiple design objects.
• Coordinated changes: Updating several objects in sequence when a change cascades.
• Sample data: Populating reference data and sample data for testing.

Using Composer for these tasks frees up your time for architecture decisions, complex business logic, and design choices that require human judgment.

Know when to work manually

Composer handles common patterns that appear in most Appian applications. For specialized configurations that require deep domain expertise or unusual patterns, manual configuration can be faster and more reliable. Composer communicates when it can't complete a task and marks it for manual work.

Common pitfalls

Avoid these patterns that commonly lead to unexpected or lower-quality results from Composer:

• Over-reliance on suggestions: Relying too heavily on Composer's output without critically reviewing it can result in plans or design objects that don't fully meet your project's needs. Always review and refine to align with your unique requirements.
• Unclear prompts: Vague prompts lead to irrelevant or incorrect results. Be specific and detailed when describing what you need.
• Skipping review: Accepting task plans or suggestions without inspection can introduce issues that are harder to fix later. Review before and after execution.
• Lack of team communication: Not communicating with your team about Composer's changes can lead to confusion or conflicting updates. Discuss suggestions and ensure alignment before finalizing.

Feedback