Skip to main content

Prepare an Application for Engage

An application manifest explains how an application should appear and behave in Engage. It connects user-facing integration choices to the workflows and data definitions that support them.

Use the manifest when the application is functionally ready and its workflows, schemas, names, and configuration choices are stable enough for another user to understand.

Before you begin​

  • Complete and test the workflows you plan to expose.
  • Publish the schemas used for events.
  • Decide which values customers can configure and which remain controlled by the application owner.
  • Confirm that you have permission to update and publish the application.

Plan the customer experience​

Before editing the manifest, write down:

  1. The business outcome each integration provides.
  2. How each integration starts, such as a schedule or webhook.
  3. Which events users need for monitoring and reporting.
  4. Which identifiers help users find an execution or business record.
  5. Which choices must be supplied during setup.

Use customer language. Avoid internal project names, implementation notes, and names that only the development team understands.

Complete the manifest​

Open the application manifest and work through each section.

Integrations​

Add the workflows that deliver a distinct customer outcome. Give each integration a unique, descriptive name, select its trigger type, and associate the correct workflow.

Events​

Define the business events that users need to observe, such as an employee being created or an order being updated. Use a published schema that accurately describes each event's data.

Identifiers​

Add stable business identifiers that users can search or use to correlate activity, such as an employee ID or order number. Do not use secrets or values that are meaningful only inside the workflow.

Application configuration​

Expose only settings a customer should reasonably control. Use clear labels, safe defaults, validation, and help text that explains the effect of each choice.

Documentation​

Explain what the application does, what users need before setup, and what outcome to expect. State important limitations and operational responsibilities plainly.

Save and review a draft​

  1. Select Save or Update.
  2. Resolve duplicate names and missing required values reported by the manifest editor.
  3. Ask someone who did not build the application to review the wording and setup choices.
  4. Confirm that every selected workflow and schema is the intended released version.

A draft can be refined without changing the published Engage experience.

Publish to Engage​

  1. Complete a final review of integrations, events, identifiers, configuration, and documentation.
  2. Select Publish.
  3. Open the application in Engage and verify the setup experience as an end user.
  4. Run a safe end-to-end scenario after publishing.

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

Publication checklist​

  • Integration names describe outcomes rather than technical mechanisms.
  • Setup fields have labels, guidance, validation, and safe defaults.
  • Events use the correct published schemas.
  • Identifiers are useful for support and investigation.
  • Documentation states prerequisites, expected results, and limitations.
  • No secrets, internal URLs, test values, or developer notes are exposed.
  • Keyboard and screen-reader users can understand the field order and instructions.