Capability, solution and activation: a capability's path
A capability starts as a draft in a studio, is published, may go into a solution, and only does work once it is opened and installed in a tenant.
For: Builder, Tenant administrator, Platform administrator, Account administrator
What a capability is
A capability is a unit that makes a business outcome possible. It has a key, a name, a category, a business purpose and versions. Each version has its own purpose and a publication status.
A capability can be built on the platform (Capability Studio) or in an account (Account Studio). A capability published by an account is visible only to that account's tenants; a capability published by another account never appears in your tenant.
The path, step by step
| Step | Where | Who | What happens |
|---|---|---|---|
| Draft | Capability Studio or Account Studio | builder (capability.write) | The capability's first version is created as a draft. A draft is not visible to any tenant and is not served. |
| Dependencies | Account Studio | builder (capability.write) | What the version needs is declared — including that it needs nothing. A version without a declaration can be published but cannot be installed. |
| Publish | Account Studio | builder (capability.publish) | The version goes live and appears on the Capabilities screen of the account's tenants. |
| Solution | Solution Studio | builder (solution.write) | Published capability versions are brought together in a solution. Only published versions can be picked. |
| Request | Capabilities in the tenant | tenant admin (scope.write) | The tenant requests the capability with Open. The status becomes “Requested, not installed”. |
| Install | Capabilities in the tenant | tenant admin (scope.write) | Install creates a plan and runs the install right away. When the screen returns, the status is “Installed” or “Install failed”. |
Why the permissions are separate
Building, publishing and switching on are different people's jobs. publish is a separate verb from write because opening something for others to use is the real risk boundary. A builder publishes but does not install in a tenant; a tenant admin opens and installs but does not write capabilities.
The steps of an install
An install is made of steps that run in order: validate the configuration, resolve dependencies, prepare the runtime, apply the binding, take the capability live and verify the activation. If a step fails, the steps after it do not run; inlorus states separately which step failed and which ones did not run because of it.