How are forms integrated

​@nav_1  Great question. Here is the short answer to your core concerns:

You do not need to run these locally, and the runner will NOT stay engaged while waiting for user input.

Here is the exact architecture for this in an unattended setup using Process Composer:

1. Split the logic to free the runner: Instead of one long Task Bot, you create a Process that flows like this: Bot 1 (Data Prep) ➔ Human Task (Form) ➔ Bot 2 (Execution) When Bot 1 finishes, the process goes into a suspended state and completely frees the runner to pick up other jobs. Once the business user submits the form, the process wakes up and assigns Bot 2 to any available unattended runner in the pool.

2. Handling Multi-Approvals: Process Composer natively supports multi-level routing. You simply chain multiple "Approval Tasks" or "Human Tasks" in your workflow. For example: Bot 1 ➔ Level 1 Form (Team Lead) ➔ Level 2 Form (Manager) ➔ Bot 2 The runner remains completely free during all of these wait times.

3. How users access Forms without CR access: Since your users don't log into the Control Room, they would use Automation Co-Pilot for Business Users. This provides a separate, simplified web interface solely for business users to interact with their pending Forms. You can even embed this Co-Pilot UI directly into enterprise applications they already use, like ServiceNow or Salesforce, so they never have to leave their normal workspace.

Hope this helps clarify the architecture! Let me know if you need any more details on setting up the Process.

Thanks for the response!
Couple more questions:
1. When you say- the process wakes up and assigns Bot 2 to any available unattended runner in the pool- how is it done? As we schedule a bot on a specific runner only. How will it switch?
2. Any links to any video course which explains this process of embedding the forms UI in already existing workspaces? or Integrating the process with external web forms?

@nav_1  Good follow-ups. Both come down to configuration rather than bot design.

1. How Bot 2 finds a runner: In Automation Co-Pilot the process is tied to a scheduler user. It is not a person, it is a middleman that tells the platform which Run as user (runner license) and which device to use. If that Run as user has a default device, the bot lands there, so you can keep your "specific runner" model. If you attach a device pool instead, it lands on whichever device is free, and it queues if all are busy. Bot 1 and Bot 2 are separate deployments, which is why the runner is free in between. See Scheduler users and device pools in Automation Co-Pilot.
2. Embedding the forms UI in an existing workspace: There are two methods: an iFrame widget for web apps that allow customization, and a Chrome extension side panel for those that do not. I do not have a full video course to point you to, but the doc page carries a short demo video of both: Embed automations in your application using Automation Co-Pilot. The same page covers deep linking, a URL that opens a specific request or task directly, which suits users who live in email.
3. External web forms: Your own web form can start the process through the Process Composer API, POST /aari/v2/requests/create, passing the process ID and the inputs. That covers the initial input. The intermediate Human Task is still completed in Co-Pilot, on the web, embedded, or through a deep link.

I’ve answered both questions, but for some reason my post it stuck. 

Here is a video for Embedded Forms