Getting Started with Orbit Resolve
What you are setting up
Resolve out of the box can accept a ticket and let an agent reply to it. Everything else — routing, clocks, classification, self-service — is configuration, and it is configuration with dependencies. An SLA target measured against undefined business hours produces meaningless breach numbers; an auto-assignment rule with no agents and no categories has nothing to match on.
The order below is the one that avoids rework. Each step depends on the ones above it — agents cannot be auto-assigned before agents exist, and an SLA cannot be measured before business hours are defined.
| # | Step | Where | Why here |
|---|---|---|---|
| 0 | Select a project | Top-bar switcher | Everything below is project-scoped |
| 1 | Business hours | Settings → Business Hours & SLAs | An SLA clock is meaningless without them |
| 2 | SLA / OLA / UC policies | same tab | Targets for customers, internal teams and vendors |
| 3 | Agents | Settings → Agents Management | Nothing can be assigned to nobody |
| 4 | Issue types | Settings → Issue Types | Decides which queues exist |
| 5 | Statuses & workflows | Settings → Statuses & Workflows | Which status pauses SLA is decided here |
| 6 | Ticket classification | Settings → Ticket Classification | Categories drive routing and reporting |
| 7 | Auto-assignment | Settings → Auto Assignment Rules | Needs agents and classification to exist |
| 8 | Catalog & knowledge | Settings → Service Catalog / Knowledge Base | What requesters can order and self-serve |
| 9 | Open the queue | /org/resolve/queue | You are live |
Statuses & workflows, custom fields, ticket classification, the service catalog and release stages each offer a Generate with AI button that drafts a starting configuration you then edit. On a new project that is usually faster than building from an empty screen — the output is a proposal, not a commitment.
Business hours are the denominator for every SLA number you will later report on. Configuring SLA targets first and business hours afterwards silently changes every breach calculation.
What each step actually asks you for
| Step | You will be asked for | Feeds |
|---|---|---|
| Business hours | Working days, start/end times, timezone, holidays | Every SLA and OLA calculation |
| SLA policies | Response and resolution targets per priority | The two dials on ticket detail |
| OLA / UC policies | Internal department targets; vendor contract terms | The Internal OLA & UC panel |
| Agents | Who works the queue | Assignment, workload, agent analytics |
| Issue types | The ticket types offered at intake | The Ticket Type dropdown in the New Ticket drawer, and per-type queues |
| Statuses & workflows | Status names, transitions, which statuses pause SLA | The Status dropdown, and clock pausing |
| Ticket classification | Category → Sub Category → Item | The three-level cascade on ticket detail |
| Auto-assignment | Rules mapping classification to agents | Who a new ticket lands on |
| Service catalog | Orderable items, intake fields, approvals | Request a Service |
When defining statuses, one property decides whether a ticket's clocks keep running while it sits in that status. Get it wrong and every breach statistic is wrong — a queue full of tickets waiting on the customer will show as your team missing targets.
Minimum viable setup
If you want tickets flowing today and will tune later, the short path is:
- Select a project.
- Add at least one agent.
- Accept the default issue types and statuses.
- Open the queue and take a ticket.
Everything else — SLA targets, classification, auto-assignment, catalog — improves the operation but is not required to accept and resolve a ticket.
Don't confuse these setup screens
| These two | Differ by |
|---|---|
| Agents Management vs Customers | Agents work tickets; customers raise them. Both are under Settings |
| Issue Types vs Ticket Classification | Issue type is what kind of ticket (Incident, RMA). Classification is what it is about (Category → Sub Category → Item). Both appear on a ticket, independently |
| Statuses & Workflows vs Release stages | Ticket lifecycle vs deployment board columns |
| Service Catalog (Settings) vs Request a Service | Authoring vs ordering |
Knowledge Base (Settings) vs Knowledge Base (/org/knowledgebase) | Customer articles vs AI training sources |