17.3 UiPath Apps: Action Apps, Automations & Integration Service

17.3 UiPath Apps: Action Apps, Automations & Integration Service

Core Concept: UiPath Apps builds web interfaces for automations, without writing front-end code. The exam description lists advanced Apps topics: action apps with their action schema, apps that call multiple automations, and apps that use Integration Service APIs. Apps are built in Studio Web (app projects) or UiPath Apps Studio.

---

What an App Is Made Of

---

Apps and Automations

An app can reference several processes, each doing part of the work. A customer service app might:

1. Run a lookup process when the agent enters an account number, filling a table with the output.
2. Run an update process when the agent edits details and selects Save.
3. Run a document process that generates a letter.

Each call passes input arguments from controls and returns output arguments that the app binds to controls. Keeping the processes small and focused makes the app responsive and each automation reusable.

Apps can also use Integration Service connectors directly, for example to read records from a CRM, without a process in between. Use a process when the logic needs UI automation or complex steps, and a connector call for simple API reads and writes.

---

Action Apps

An action app is an app used as the interface of a task in Action Center. It replaces a form task when you need a richer interface.

Building an action app

1. Add an Action control to the app (via Add control). Only one action per app is allowed. Once deployed, the app is opened through Action Center.
2. The Action Properties schema opens. It starts with one input property and one Submit outcome.
3. Add properties of the kinds you need:
   • Input: data the workflow sends to the task.
   • Output: data the reviewer returns.
   • In/Out: data sent to the task that the reviewer can change. Property names must follow VB naming conventions, you can mark properties required, and complex types such as objects support sub-properties.
4. Map inputs and in/out properties to input controls. A required input or in/out property should be mapped to an input control.
5. Add outcomes such as Approve and Reject. Each outcome is mapped to a Submit Action rule, typically on a button's Click event.
6. Publish the app, then deploy it to an Orchestrator folder (Automations > Apps > Deploy app).

Using it from a workflow

In a long-running workflow, Create App Task creates the task with a title, priority (TaskPriority.Low, Medium, High, or Critical), the deployed action app, and values for the schema's properties. Wait for App Task and Resume suspends the job until the reviewer submits an outcome, then returns the task data, including outputs and the chosen outcome.

The action app can also be a Coded Action App, a custom React or Angular application built in your own IDE.

---

Action App Versus Form Task

---

Worked Example: Credit Limit Approval

1. The action app's schema has inputs CustomerName and RequestedLimit, an in/out property ApprovedLimit, and an output Comment, with outcomes Approve and Reject.
2. The app shows the customer's history by calling an Integration Service connector for the CRM when the page loads.
3. A long-running process runs Create App Task with the request values and then Wait for App Task and Resume.
4. The reviewer lowers ApprovedLimit, adds a comment, and selects Approve, which runs the Submit Action rule with that outcome.
5. The process resumes, reads the outcome and ApprovedLimit, and updates the ERP.

---

Common Traps

• Only one Action control per app.
• An outcome only works when mapped to a Submit Action rule.
• An action app must be deployed to an Orchestrator folder before Create App Task can use it.
• Required input and in/out properties need input controls.