Skip to main content
New Participant
Oct 30, 2026 11:31 AM UTC

Appian Composer - Cannot build AI Skills - Does not understand subprocess logic

I wanted to share some feedback on Appian Composer after reviewing an app that was generated with it. My manager used Composer to build out an app idea, and when I went in to verify functionality, I ran into several issues worth flagging.

1. Unnecessary API for existing data
Composer built an API to pull data that was already available through JDBC. This added complexity with no real benefit.

2. Broken PDF generation subprocess
The subprocess responsible for generating a PDF was using an incorrectly formatted template PDF, so document generation didn’t work as expected.

3. Misunderstanding of subprocess to parent data flow
Composer seemed to have an incorrect understanding of how data is passed from a subprocess back to the parent process, which caused the process model to keep failing. When I instructed it to stop passing the data back from the subprocess and instead add a script task in the parent to fetch the document ID, it was not able to implement that change.

4. Activity chaining removed on every edit
Each time Composer edited the process model, it removed activity chaining. As a result, users could not complete the process in one continuous session. I had to go into the process model and re-enable activity chaining manually.

5. Outdated functions and version hallucinations
Composer doesn’t appear to have an accurate understanding of its own platform. It frequently referenced incorrect Appian functions and versions. For example, it used the 20.4 version of a!queryRecordType instead of the current version for our 26.9 environment.

Summary
Composer was useful for getting an idea into a rough working shape quickly, but the output needed significant developer review and rework before it was functional. The biggest concerns for me were the process model behaviour (subprocess data flow and activity chaining) and the use of outdated function versions.

Has anyone else run into similar issues? I’d be interested to hear if there are any workarounds or prompting approaches that have worked better for you.

6 replies

mathieud0001
Genius
Oct 30, 2026 11:57 AM UTC

I personally prefer to use Dev MCP. You have control over the model being used in the backend and I find it more flexible than composer.

New Participant
Oct 30, 2026 2:19 PM UTC

I’ve built a cloud-based folder structure that I upload application exports to. Each application is partitioned into its own folder, and the application details are converted into Markdown files. I use this repository as a reference when developing new apps: I copy over any interfaces I need, and use Composer to create the database and process model structure.

To work with the codebase, I use Claude Code and Cowork with Opus 5.5.

My questions:

  1. Is this a reasonable approach, or am I going about it the wrong way?
  2. Should I be using an MCP connection (e.g. Appian MCP Server) instead of, or alongside, maintaining my own project structure externally?

I’d be interested to hear how others are integrating AI tools into their Appian development workflow.

mathieud0001
Genius
Oct 30, 2026 7:10 PM UTC

I’m a bit confused - your original question pertained to composer but now you seem to say that you are using Claude Code and/or CoWork.

In any case, the approach you describe seems a little convoluted (at least in my perspective)

I would recommend using Appian Dev MCP which interacts directly with the code base of your dev instance.

shubhama926776
Brainy
Nov 2, 2026 4:30 AM UTC

Most of this is expected. Composer can’t build AI Skills or any AI/Automation object, and subprocess data only returns to the parent from a synchronous subprocess via Output Variables.

Better route: drive the Dev MCP yourself. Same tool layer, but you pick the model, feed full environment context and your own .md instructions, and plan before it writes. Composer is the guardrailed version with far less control.

शुभम्