Starting an engagement
Engagements → New engagement (/engagements/new). You need permission to
create engagements (the engagement lead or a platform administrator).
The client
Section titled “The client”Pick an existing client, or create a new one. Each client is a separate tenant — its own isolated knowledge graph and document store. Multiple engagements for the same client share that client’s graph, so a follow-on engagement starts with everything the last one approved.
Engagement details
Section titled “Engagement details”- Engagement ID and name — the ID is how the engagement is referenced everywhere; pick something short and stable.
- Type — Migration (the client is moving off an existing tool or platform), Greenfield (a fresh build from discovery), or Other.
- Delivery framework — SAFe, Scrum, Kanban, LeSS, or Other. This shapes the implementation roadmap later.
- For a migration, the tool being migrated from.
Assign the engagement lead at creation. The rest of the team is added
afterwards on the engagement’s Team page (/engagements/{id}/team), where
you also set each role’s permissions — see
Roles and what they can do.
Default standards
Section titled “Default standards”Leave “pin default standards” on unless you have a reason not to — it seeds the engagement with the deployment’s standard framework and playbook selections so Phase 1 isn’t starting from nothing.
Seeding from a previous engagement
Section titled “Seeding from a previous engagement”If this is a follow-on for the same client, you can carry forward:
- Framing objectives and success criteria — as draft starting points for Phase 1.
- Baseline standards — re-use the previous framework and playbook choices.
- Residual gaps — unresolved gaps become candidate gaps in the Phase 2 register.
- Deferred recommendations — surface again during Phase 3.
Each is optional and each is a draft — nothing is carried in as already approved.
Once created, the engagement opens at its overview page, ready for Client discovery.