Introduction to Engage
Engage is where an integration is watched after it is built. Studio is the application the developer works in; Engage is the console an operator works in. The two share one description of each application, the manifest, and nothing else has to be configured twice.
An operator in Engage sees a table of executions for each integration, with a status and the business data the workflow chose to report. When an execution fails, Engage records it as a fallout, and the operator investigates it there rather than in the workflow.
Who uses Engage
| Role | What they do in Engage |
|---|---|
| Operator | Watches executions, investigates failures, retries what can be retried |
| Application owner | Provisions the application and decides which data operators see |
| Administrator | Manages members, teams, tenants, and sign-on |
The developer who built the application usually stays in Studio. Their part of the journey is the manifest, described in Prepare an Application for Engage.
Read next
Engage and Studio
The boundary between the two products, and how a published manifest becomes a provisioned application.
See the boundaryKey concepts
The vocabulary the rest of this section uses.
Learn the termsWhere to start
Read Engage and Studio first. It explains the one fact every later page depends on: an application appears in Engage only after its manifest is published from Studio and synced into Engage.