Prepare an Application for Engage

An application manifest describes an application to Engage: which workflows start it, which events it reports, and which identifiers make an execution findable. Each application has its own manifest, so two applications in the same workspace can be described completely differently.

Publishing the manifest is what makes the application available to Engage. Until you publish, the application does not appear in Engage's provisioning list at all.

Configure the manifest when the application is functionally ready and its workflows, schemas, and names are stable enough for someone else to understand.

Before you begin

• Complete and test the workflows you plan to expose.
• Publish the schemas you plan to attach to events.
• Confirm you have permission to view the application manifest. Publishing needs a separate permission again — without it the Publish button stays disabled and its tooltip says so.

Open the manifest

1. Open the application in Studio.
2. Select Manifest in the application header toolbar.

The manifest opens as a panel with five sections — Integrations, Events, Identifiers, Retry Workflows, and Documentation — and a status tag reading either Draft or Published.

note

Selecting Tour in the panel footer walks through the sections in the product itself.

Describe the integrations

An integration is one entry point into the application. Add one for each distinct outcome the application delivers.

1. In Integrations, select the workflows that start this integration in Select Trigger Workflows.
2. Enter a name in the Integration Name field.
3. Select the Integration Type.
4. Enter a Description. This field is optional.

An application can have more than one integration, each with its own trigger workflows.

Choosing the integration type

Type	Use when
File	The integration reads or writes a file at any stage.
API	The integration only makes API calls, with no file operations anywhere.

The type follows file operations, not API calls. An integration that reads a file and calls an API is File, not API — the presence of an API call never makes an integration API.

Define the events

An event is a business milestone the application reports to Engage. Its schema defines the data sent each time the event fires.

1. In Events, enter a name in the Event Name field.
2. Attach the event's Schema. Select Upload to attach one, or View to inspect a schema already attached.
3. Enter a Description. This field is optional.

Repeat for each event the application reports.

Not every workflow action is an event, and not every workflow needs one. Define events for operations someone will want to monitor or report on. In a large integration, defining an event per action produces noise rather than visibility.

Each event you define here becomes selectable in the Send to Engage activity, which is how a workflow actually sends the data.

Add identifiers

Identifiers are business values that make an execution findable in Engage — an employee ID or an order number, for example.

1. In Identifiers, enter a name in the Field Name field.
2. Select Required if the value must always be present.
3. Enter a Description. This field is optional.

This section can be left empty. An application with no identifiers publishes normally.

Do not use secrets, or values that are meaningful only inside the workflow.

Add retry workflows

Retry workflows let an Engage operator reprocess a failed record by calling back into the application.

1. In Retry Workflows, enter a name in the Name field.
2. Choose the workflow to call in Select Workflow.
3. Select the HTTP Method — GET, POST, PUT, PATCH, or DELETE.
4. Enter the Request Path.
5. Enter a Description. This field is optional.

Write the documentation

The Documentation section holds the readme an Engage user reads before setting the application up.

1. In Documentation, select Generate a Readme to draft one from the manifest you have configured.
2. Select Edit to revise it.

Explain what the application does, what someone needs before setup, and what outcome to expect. State limitations plainly. Use customer language — avoid internal project names and notes that only the development team understands.

Save and publish

1. Select Save, or Update if the manifest already exists.
2. Select Publish.

Publish stays disabled until the manifest has been saved at least once, so save before you look for it. Once the manifest is published the button is removed entirely — a published manifest is updated with Update, not published again.

If required values are missing, the panel reports the field names and scrolls to the section that needs attention.

How you know it worked

The status tag reads Published, and a confirmation appears. In Engage, the application now appears in the list shown by Provision Application.

When it does not work

Symptom	Cause	What to do
Publish is disabled and the tooltip mentions access	You do not have permission to publish application manifests	Ask a workspace administrator to publish, or to grant the permission
Publish is disabled with no tooltip	The manifest has not been saved yet	Select Save, then Publish
The application does not appear in Engage's provisioning list	The manifest is saved but not published	Reopen the manifest and check the status tag reads Published
The panel reports missing fields on publish	A required value is empty in one of the sections	Use the reported field names; the panel scrolls to the section

Publication checklist

• Integration names describe outcomes rather than technical mechanisms.
• Integration types follow the file-operations rule, not the presence of API calls.
• Events use the correct published schemas, and exist only for meaningful operations.
• Identifiers are useful for support and investigation, and expose no secrets.
• Documentation states prerequisites, expected results, and limitations.
• No internal URLs, test values, or developer notes are exposed.

Updating a published manifest changes what Engage users see. Treat substantial naming, configuration, or event changes as product changes and communicate them before publishing.

Next steps

With the manifest published, configure the application on the Engage side: provision it, add columns from the event schemas, map each event to those columns, and build the views operators will work in. See Onboarding an application.