# Assignment Assignment decides who owns a request and where it is worked. In Siit you can set it once as a default, automate it with rules, or change it on the fly. The right mix keeps work flowing without handoffs or guesswork. ### Where assignment happens * **In the Service** — set a default team inbox or a specific owner for every request created from that service. * **Per Team Inbox** — choose an assignment method (Manual, Round-robin, or Balanced) so new requests are auto-distributed to the right teammate. * **With Business Calendars** — assign a Business Calendar to an admin so routing respects their actual working hours. Requests are routed to admins who are currently within their calendar's active hours. * **In Workflows** — route based on conditions — service, department, office, form answers — and assign to an inbox or a person. * **In the Request** — agents can manually change the inbox or assignee from the sidebar. If you move a request to an inbox with auto-assignment, Siit assigns it according to that inbox's method. ### Service-level defaults Use the Service Catalog to decide where requests should land by default. When an employee selects a service in Slack/Teams or the portal, Siit: 1. Creates the request with your pre-selected inbox or owner 2. Applies the service's SLA policy 3. Runs any related workflows
**Tips:** * Point repeatable services to a team inbox rather than an individual, then let the inbox method distribute the work. * For single-owner services (e.g. "Legal review"), assign to a specific person and add a fallback rule in workflows in case they're unavailable. ### Team inbox methods Each inbox can automatically distribute new requests to its members. Go to **Inbox settings → Assignment** to configure. * **Manual** — nothing is auto-assigned. A dispatcher or agents pick up work. * **Round-robin** — assignments rotate in sequence across available teammates. * **Balanced** — assignments go to the teammate with the fewest active requests.
**Notes:** * Auto-assignment triggers whenever a request enters the inbox — via service defaults, workflows, or manual move. * "Assign to me" always overrides the method. You can unassign or reassign at any time. Workflow-based routing and assignment For fine‑grained control, use the Assign to action in a workflow. Combine it with conditions such as: * Request data: service, channel, tags, priority, status. * Requester attributes: department, location, employment type, manager. * Form answers: app selected, office, device type, urgency. Examples * App access from Sales → assign to IT Ops inbox; if target app = “Salesforce,” assign to CRM admins. * Requests created from #hr‑help → assign to People team and set priority = Normal. * If status becomes Waiting and the requester replies → reassign to the previous owner and resume SLA. ### Excluding admins from inbox assignment Within the Assignment tab, you can exclude specific team members from automatic assignment. Excluded admins remain members of the inbox — they can still view requests, pick up work manually, and be assigned directly — but the auto-assignment method skips them. Go to **Inbox settings → Assignment → Exclude team members from inbox assignment** and add the admins to exclude.
**When to use this:** * A team lead or manager who needs inbox visibility but shouldn't carry a request queue * An admin on a temporary reduced schedule, is off or transitioning between teams * A specialist who handles only escalations, not first-touch requests ### Routing rules Routing rules let you adapt assignment behavior beyond the base method. Go to **Inbox settings → Routing rules** to configure.
#### When no admin is available, auto-assign to next one available When all admins are at capacity or outside working hours, this rule holds the request unassigned and automatically assigns it to the next admin who becomes available — without manual intervention. Enable this to prevent requests from sitting permanently unassigned when the inbox is momentarily at full load. #### Set a max number of open requests Cap how many active requests any single admin can hold at once. When an admin reaches the limit, new requests skip them and go to the next eligible teammate. Configure: * **Max number** — the cap per admin * **Don't include when** — choose which statuses don't count toward the cap: Waiting, Snoozed, or Pending approval This prevents overloading specific admins and keeps workload distribution accurate, especially when using the Round Robin assignment method. #### When an admin has capacity available, auto-assign unassigned requests When an admin drops below their cap or becomes available, this rule automatically pulls unassigned requests from the inbox queue and assigns them — no dispatcher needed. Configure the **prioritisation** order for which unassigned requests get picked up first, for example Most urgent first. Enable this alongside the max open requests cap to get a self-balancing queue: requests wait in the inbox, then flow automatically to admins as capacity opens up. ### Availability-based routing with Business Calendars Assign a **Business Calendar** to an admin to define their working hours. When availability-based routing is active, Siit uses these calendars to determine which admins are currently "online" for assignment purposes.
**How it works:** * When a request arrives, Siit routes to admins who are currently within their calendar's working hours. * If no admin is within working hours, the "When no admin available" routing rule handles what happens next. * This removes the need for manual triage across time zones or shifts. **Example:** Your inbox has three admins — one in Paris (CET), one in New York (ET), one in Singapore (SGT), each with their respective Business Calendar assigned. A request arrives at 2pm CET: only the Paris admin is within working hours, so Siit routes to them automatically. Configure Business Calendars in **Settings → Business Calendars**. ### Workflow-based routing and assignment For fine-grained control, use the **Assign to** action in a workflow. Combine it with conditions such as: * **Request data:** service, channel, tags, priority, status * **Requester attributes:** department, location, employment type, manager * **Form answers:** app selected, office, device type, urgency **Examples:** * App access from Sales → assign to IT Ops inbox; if target app = "Salesforce," assign to CRM admins * Requests created from #hr-help → assign to People team and set priority = Normal * If status becomes Waiting and the requester replies → reassign to the previous owner and resume SLA ### Manual assignment in a request From the request sidebar you can: * **Change Inbox** to move the request between teams. If the destination inbox uses Round-robin or Balanced, Siit auto-assigns to a teammate there. * **Change Assignee** to a specific person or click "Assign to me." * **Unassign** when you need the inbox method to pick the next owner. All changes are logged on the timeline for audit and reporting.
### Best practices * Set defaults in Services for the 80% path. Use Workflows for exceptions. * Prefer inbox assignment over naming individuals — it's more resilient to PTO and turnover. * Use the **max open requests** cap with **Balanced** assignment to get accurate load distribution, not just round-robin fairness. * Enable **auto-assign when capacity opens** alongside the cap so the queue drains automatically as admins free up. * Use **admin exclusions** for managers or specialists who need inbox visibility but shouldn't take first-touch requests. * Use [**Business Calendars**](/workspace/business-calendars.md) for teams across time zones or shifts to enable availability-based routing automatically. * Keep team membership, exclusion lists, and Business Calendar assignments current — auto-assignment only considers eligible, available admins. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.siit.io/request-management/assignment.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.