> 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/understand-the-service-model.md).
# Understand the service model
A service defines an outcome, the work needed to deliver it, and the evidence used to check it. Use **Services** to design that reusable definition; use **Service Cases** and **Pulse** to follow its operation.
### Choose the right object
| Object | What it is for | Where to start |
| ------------ | ----------------------------------------------------------------------------- | --------------------------- |
| Work item | A reusable unit of Govern, Execute, or Prove work | **Build → Work Items** |
| Service | An outcome definition and lifecycle composed from released work-item versions | **Execute → Services** |
| Deployment | The deployment area for services and their environment-specific setup | **Execute → Deployments** |
| Service case | The operational record whose status and result describe a service request | **Execute → Service Cases** |
| Pulse | Current case health and period-based outcome measures | **Execute → Pulse** |
| Foundation | Shared configuration that services can reference at deployment | **Execute → Foundation** |
### Follow the four phases
{% code collapsedlinecount="10" %}
```mermaid
flowchart LR
A["Engage Request or trigger"] --> B["Govern Eligibility, rules, approvals"]
B --> C["Execute Work that delivers the outcome"]
C --> D["Prove Independent outcome verification"]
```
{% endcode %}
**Engage** defines how a request enters the service. The Dublin designer offers API/webhook and Schedule entry types. Each type can be added once.
**Govern** holds eligibility checks, rules, and approval work. **Execute** holds the automation work that delivers the promised outcome. **Prove** holds independent verification. These three phases use work items and have **Phase behavior** configuration in the service wizard.
The designer requires at least one Execute work item before continuing. A work item added to a service must use a **released version**.
### Start with one clear outcome
For an initial service, choose a small result that can be checked. For example:
* **Promise:** validate a supplied access request and return a clear result.
* **Criteria:** required fields are present and the validation result is recorded.
* **Execution:** perform only the validation work required for this first version.
* **Proof:** check the recorded result against the criteria.
This is a design example, not a ready-made service. Expand the service after its first outcome and verification path are clear.
### Read operation and outcome separately
Service Cases distinguishes **Status** from **Result**. A case with **Done** status can have **Success**, **Partial success**, or **Failed** as its result. Done alone is therefore not proof that the promised outcome was achieved.
Continue with [Define a service](/userguide/service-automation/define-a-service.md), [Add work items](/userguide/service-automation/create-work-items-and-pin-released-versions.md), and [Read service-case status and result](/userguide/operate-and-troubleshoot/read-service-case-status-and-result.md).
### Dublin 6.0.0 limitations
The Dublin service designer explicitly states that identity and access policy are not part of this version. Foundation also marks Approval Policies, Access Policies, and Time & SLA as **Coming soon**. Do not design a dependency on those Foundation features as though they were available.
