How the Pieces Fit

BareBones Ticketing stores a small set of objects. Every later page in this manual talks about them. This page names each one and says what it attaches to.

The objects

Department is the boundary

Department is the object everything else hangs from. A ticket names exactly one department, set when it is created. Services, workflows, SLA policies, and projects each belong to one department.

Access is department-scoped. A user does not hold department access directly: the user belongs to groups, and a group is mapped to a department at an access level. That access applies only to the department it was mapped for, and access to one department reveals nothing about another. See Roles and access for what each level permits and how the effective level is worked out.

Service decides how a request is handled

A service is one entry in the catalog — "New laptop", "Access request". A requester picks a service, and the service determines the shape of the intake form and what happens next.

A service can name a default workflow and a default SLA policy. Both must belong to the same department as the service. A ticket does not have to have a service; a request raised through Quick Ticket can arrive without one.

Workflow and status

Statuses are defined once for the whole installation, not per service or per department. Each status carries a category, whether it is terminal, and whether it pauses SLA timers.

Defining a status makes it available; each workflow then selects the ones it needs by naming them in its transitions. So a single shared vocabulary of statuses supports processes that differ department by department, and a status comes into use in a department at the point one of that department's workflow transitions names it.

A workflow belongs to a department and lists which status-to-status transitions are permitted, under what conditions, and with what prompts or approval gates.

Which workflow governs a given ticket is decided in this order:

1. The workflow named by the ticket's service, if the ticket has a service, that service names a workflow, the workflow is active and in the same department, and the workflow has at least one transition defined.
2. Otherwise, an active workflow belonging to the department. A department can have more than one; the product does not prevent that. It picks the one marked default, then the most recently updated, then the lowest identifier.
3. Otherwise, the product's built-in default transition map. That map applies to agents only. A Customer Portal requester is refused every transition in it.

Only a System Administrator creates or changes statuses, workflows, SLA policies, or business calendars. Department Admin access does not include this.

SLA

An SLA policy sets a first-response target and a resolution target, in hours. Each target independently chooses how its time is counted: 24/7 wall-clock, or the working hours of a bound business calendar. Each also carries its own warning threshold, defaulting to 25 percent. When a ticket is created and a policy applies, an SLA instance is created for that ticket to track its due dates, whether the targets were met, and whether either was breached.

Which policy applies is decided at creation: the ticket's service default if it names one and that policy is usable, otherwise the ticket's department. The fallback is silent, so a service whose named policy has been deactivated ends up on the department's targets with nothing to indicate it.

A status marked as pausing SLA records paused time, and that paused time is credited consistently — to what the queue displays, to when a warning is raised, and to the breach decision. A paused ticket is not pushed into breach by time it spent paused.

Due dates behave differently by mode. On a 24/7 target the due date is written once at creation and never moved; the paused time is instead subtracted when the target is assessed. On a business-hours target the due date itself is extended when the ticket resumes.

A background worker polls for breaches rather than waiting for someone to open the ticket.

Project

A project groups related work. It belongs to a department and has its own reference, workflow, and status, separate from any ticket's. Unlike a ticket reference, which the product allocates, a project reference is one you type — any unique text up to 64 characters. The create screen suggests a department key, PRJ, and a number, as in IT-PRJ-1. Nothing enforces that shape, but a distinguishable one is worth having: the queue's Ticket or project reference filter accepts either kind.

A ticket can carry one project association. Project role slots can be staffed with users, and a routing rule can set a new ticket's owner, watchers, or participants from that staffing when the ticket is created, when it transitions, or through a bulk operation.

Project association and ticket access are separate facts. Linking a ticket to a project does not reveal that ticket to the project's staff, and being staffed on a project grants no department access.

Users, groups, and the people named on a ticket

A user is one account. It can come from a local sign-in, from your company's directory, or from single sign-on. Groups carry department access: a directory group or a single-sign-on group maps to a product group, which maps to a department.

Separately, a user can be named on an individual ticket as its requester, owner, watcher, or participant. That gives visibility of that one ticket and adds no department access.

Related pages

• Roles and access
• Configure departments, services, and workflows
• Work tickets
• Glossary