Example: From Empty To A First Working Service

This example takes a fresh installation — first administrator created, nothing else configured — to one service a requester can submit from the Service Catalog, whose ticket is assigned to a named owner the moment it is created and then moves through an active workflow to closed.

It is a sequence, not a reference. Each step names the controls it uses and links to the page that owns the full procedure. Every workspace it opens is SystemAdmin-only and behind step-up — see Admin Settings and step-up.

Why this order

Each object in the chain refuses to exist, or silently does nothing, until the one before it is in place:

The example uses a running scenario — a Service Desk department offering one General IT help service, owned by one agent — so every value is concrete. Substitute your own names.

1. Create the tenant

Open Admin Settings, then Tenant Administration, and select Create tenant — the button exists only while no tenant does. Enter the organization identity and save. The first tenant is permanent for the life of the database, so name it for the organization, not the project. See Tenant and organization.

2. Define the statuses

A fresh installation has no statuses, and a ticket cannot be created without one: the product opens new tickets in the active status whose key is NEW, falling back to the first active non-terminal status, and refuses creation if neither exists.

In Status Definitions, create four (see Workflows and statuses):

These four keys are also the vocabulary of the built-in fallback workflow, so any ticket that ever lands on the fallback still has a full lifecycle.

3. Create the owner, their group, and the department

1. In User Administration, select Add local user and create the person who will own new tickets — username, display name, initial password, and a ticket-email contact if they should receive ticket mail. See Users and groups.
2. In Group Administration, select Create local group — Service Desk agents — and add that user as a member.
3. In Department Administration, select Add department — name Service Desk, key SDESK (2 to 12 characters; letters, numbers, underscores). See Departments and access.
4. In Department access administration, choose the department, select Manual access, then Add manual access: the group, at Work.

That mapping is what makes the user an eligible fixed owner — and it is the moment they start counting against your licensed worker limit. See Editions.

4. Build and activate the workflow

In Workflow Administration, choose the department and select Add workflow — Service Desk standard. Add four moves (full procedure in Workflows and statuses):

No prompts, requirements, or approval gates — add those later, where the process truly needs one. Then, still in the workflow: select Use this workflow for new tickets, make it the department default if you want the department's other services covered too, and Save workflow changes. A workflow left inactive governs nothing, and activation affects only tickets created afterwards.

5. Create the category and the service

1. In Service Categories, select Add category — key GENERAL, display name General requests. See Services and the Service Catalog.
2. In Services, select Prepare a new service:
   • Department — Service Desk.
   • Category — General requests.
   • Service name — General IT help, plus the description requesters see.
   • Default workflow (optional) — Service Desk standard.
   • Fixed owner for new tickets (optional) — the user from step 3. The control accepts only an active person with Work or stronger access in that department, which is why the mapping came first.
3. Select Create service once, then reopen it and confirm the saved department, category, and defaults.

The fixed owner assigns at ticket creation, and only when nothing earlier in the create-time order assigned one — select-field owner rules run first, then project-linked routing. This example configures neither, so the fixed owner always lands. See Assignment rules.

6. Submit a ticket and watch it route

As any signed-in internal user (see Submit a request):

1. Open Service Catalog and find General IT help.
2. Select Add to tickets, fill in Ticket title and Tell us what you need, and select Submit 1 ticket.
3. Open the created ticket from the submission summary or My Tickets.

7. Work it to closed

Sign in as the owner. The ticket is in New, already assigned to them, with the SLA signal reading No SLA — this example configures no SLA policy, and that is fine. From the Agent queue, open the ticket and take it through Start work, Resolve, and Close. See Work a ticket and Workflow actions.

Check it worked

• The new ticket opened in New and named the fixed owner from the moment it was created — ticket History shows the create-time routing.
• The three workflow buttons appeared in order, and the ticket ended Closed.
• Status Definitions refuses to deactivate a status while live tickets sit in it — a sign the lifecycle is really in use.

What this example leaves out, deliberately

SLA policies and business calendars, intake questions (custom fields), approvals, project routing, the Customer Portal, and mail. Each bolts onto the objects built here without rebuilding them — the service can be given a Default SLA policy later, moves can gain prompts and gates, and Customer Portal visibility is a separate switch on the service. Add one at a time and re-test with a fresh ticket.

If it does not work

• Ticket creation is refused outright. Check the tenant exists and at least one active non-terminal status does — step 2 is not optional.
• The service will not accept the fixed owner. The person is inactive, or their group mapping is missing, inactive, or below Work. Fix the mapping, not the person's role.
• The ticket was created unowned. The fixed owner became ineligible after the service was saved, or something earlier in the create-time order was configured and stood down. Read the ticket's history for the recorded reason.
• The moves do not appear on the ticket. The workflow was never turned on for new tickets, or the ticket was created before it was activated and resolved to the built-in fallback instead.

Related pages

• How the pieces fit
• Departments and access
• Workflows and statuses
• Services and the Service Catalog
• Assignment rules