> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/service-automation/msp-edition-overview-and-first-service.md).

# MSP Edition: overview and first service

Learn the MSP and tenant responsibilities, then prepare your first reusable service.

MSP Edition is for teams managing automation and reusable services across customer tenant environments. Start in **MSP Hub** to manage the service portfolio, then use the tenant selector when working in a particular customer's context. Keep the reusable service definition separate from each tenant's deployment and credentials.

#### Understand the two working contexts

| Context            | Use it for                                                                                                                                                                         |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **MSP Hub**        | The provider-level workspace. In the inspected interface, **Execute Beta** opens Pulse, Service Cases, Services, Deployments and Foundation.                                       |
| **Tenant context** | Work within the selected customer environment. Check the tenant name before viewing or changing its resources. Menus depend on the available feature set and the account's access. |

Use MSP Hub for the provider-level service portfolio and operations. Switch to the relevant tenant when working on that customer's resources.

#### Know what you are reusing

| Object                | Practical role                                                                                                        |
| --------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Work Item**         | A reusable Hyperflow that performs Govern, Execute or Prove work. Release a version before selecting it in a service. |
| **Service blueprint** | A versioned definition of the outcome and its Engage → Govern → Execute → Prove lifecycle.                            |
| **Deployment**        | The service version, target tenant, execution agent, inputs and configuration used for that deployment.               |
| **Service Case**      | The operational record of one request, including its pinned context, phase journey, Status and Result.                |

For example, a common access-request service can reuse the same blueprint while its deployments select the appropriate tenant context and application connections. This is a design pattern; start with an isolated test before connecting customer systems.

## Example reuse request intake for two customers

Imagine the same request-intake service is offered to **Demo North** and **Demo South**. Both need the same service logic, while their request data and deployment configuration belong to their own customer context.

{% code collapsedlinecount="10" %}

```mermaid
flowchart TD
  A[Published request-intake service] --> B[Demo North deployment]
  A --> C[Demo South deployment]
  B --> D[North request and execution context]
  C --> E[South request and execution context]
```

{% endcode %}

| Shared definition                    | Customer-specific selection                              |
| ------------------------------------ | -------------------------------------------------------- |
| Service promise and success criteria | Intended tenant                                          |
| Released Work Item versions          | Allowed Mate Agent and application connections           |
| Request-summary logic                | That customer's request/input values                     |
| Phase behavior in the blueprint      | Reviewed deployment bindings and any deliberate override |

Use fictional data when trying this pattern. A useful first acceptance test submits `REQ-DEMO-NORTH-001` to North and `REQ-DEMO-SOUTH-001` to South, then inspects each resulting Case's tenant and resolved input. These are sample request identifiers, not predefined product fields; map them through the service's real input contract.

The fixed-string first Hyperflow is a construction lesson. Before reusing it for different requests, replace the literal with explicit inputs and inspect those values in a controlled run. Reuse means sharing the intended logic while verifying each deployment's data and execution context.

#### Prepare your first service

Before starting, confirm the MSP edition/build, an approved test tenant, access to a suitable Mate Agent and the application credentials required by the service.

1. Define one small outcome and its success criterion. Start with supplied request data and no customer-system changes.
2. Build and release the required Work Items under Build → Work Items. Create and publish the service version with at least one Execute Work Item.
3. In MSP Hub, open the ready service and select Deploy. Choose the tenants that should receive the service.
4. Select the Work Items to include for those tenants. Configure the credentials and fields in Engage, Govern, Execute and Prove.
5. Review the tenant, service version, Mate Agent, bindings and phase settings. Deploy creates a draft for the selected tenant; check the service-to-tenant association in Deployments.
6. Send a controlled development request using the generated service URL and its \&dev flag. Use the real input contract and keep credentials and secret-bearing URLs private.
7. Open the matching Service Case. Check the tenant, version, package, environment, Status, Result and action data against the expected result.
8. After the draft passes the required tests, use the live transition for that deployment. The dev marker is removed and the API entry targets live. Keep the intended environment clear when sharing the entry with callers.

The deployment walkthrough shows the separate Enterprise draft example. For the MSP tenant procedure and access checks, continue to the MSP deployment guide. See [deployment walkthrough](/userguide/service-automation/create-an-enterprise-service-deployment-draft.md).

Continue with [MSP service deployment](/userguide/service-automation/deploy-a-service-to-msp-tenants.md).

#### Reuse and update deliberately

Releasing a Work Item does not update every service automatically. Create a new service version, explicitly select the new Work Item version and publish it. Draft and live are separate packages: a new service-version selection does not replace an existing draft. Use the MSP deployment guide’s new-draft procedure, then check one controlled tenant before extending the configuration.

For each tenant, verify the selected runtime, credentials, input bindings and permitted users. Shared definitions do not remove the need to review tenant-specific access. Use [MSP deployment and access validation](/userguide/service-automation/deploy-a-service-to-msp-tenants.md) for the detailed checklist.

#### Current boundaries

Deployment owner assignment is planned for a later version. Use MSP Hub for the Service Automation operational views described here; the inspected tenant menu did not include tenant-level Service Cases.

The tenant deployment steps follow the engineering-confirmed procedure. Run tenant and role-isolation checks in an MSP-enabled test environment; the Presales Enterprise examples do not cover them. Separate account and tenant-isolation tests remain pending. Review permitted actions with your administrator before handing the environment to operators. See [user and access responsibilities](/userguide/administration-and-runtimes/manage-users-and-access.md).