Engage and Studio
Koodisi ships two applications you can be inside: Studio, where an application is built, and Engage, where it is operated. Almost every question about "why does Engage not show my application" is a question about the boundary between them, so it is worth knowing exactly where that boundary sits.
What lives where
| Concern | Product | Where |
|---|---|---|
| Workflows, schemas, and the activities that report data | Studio | The application |
| The manifest: integrations, events, identifiers, retry workflows, documentation | Studio | Manifest in the application header toolbar |
| Publishing the manifest | Studio | Publish in the manifest panel |
| Making a published manifest visible | Engage | Sync Manifests in the Provision New Application drawer |
| Installing the application | Engage | Install in the same drawer |
| Which fields are stored, how events map to them, which views exist | Engage | The integration's Configure form |
| Executions, fallouts, alerts, retries | Engage | The application's pages |
The manifest is written once, in Studio, and read in Engage. Engage never edits it. If an integration's type or name is wrong in Engage, the fix is in Studio, followed by a sync.
How an application reaches Engage
- In Studio, a developer configures the manifest and selects Publish. Until this happens the application does not exist as far as Engage is concerned. See Prepare an Application for Engage.
- In Engage, an operator opens Applications > Provision Application and selects Sync Manifests. This pulls every manifest published to the organisation. A manifest published a minute ago is not in the list until this step runs.
- The operator chooses the manifest and selects Install. Engage creates an application from it, with one integration per manifest integration and one event per manifest event.
- The operator configures each integration: which columns to store, how each event maps to them, and which views to show. See Onboarding an application.
- A workflow runs in Studio. Each Send to Engage activity reports one manifest event with data mapped to that event's schema.
- Engage receives the event, applies the mapping, and the record appears in the views built on those columns.
Steps 1 and 5 happen in Studio. Everything else happens in Engage.
When the manifest changes after provisioning
A manifest is not frozen by provisioning. When a developer selects Update on a published manifest in Studio, Engage does not pick the change up on its own.
To bring the change across, open the application in Engage, select the Configuration tab, then Integrations, and select the sync control beside the search box. Engage confirms with Application synced successfully and reloads the integration list from the manifest.
Adding an event to the manifest makes that event available in the integration's Event Mapping table after the sync. Renaming a field in an event schema does not rename the column it was mapped to; check the mapping after any schema change.
What the boundary does not carry
- Tenant names and organisation settings are Engage's own. Nothing in the manifest refers to them.
- Workflow logic stays in Studio. Engage can call a retry workflow the manifest names, but it never edits one.
- Schemas cross the boundary only as the shape of an event. Engage stores what the mapping puts into its columns, not the raw payload.