Automation
Roles
The Roles page is where admins define what teammates are allowed to do inside Sift. Every member of your organization is assigned one or more roles, and each role is a bundle of permissions - what they can see, what they can change, and which queues they can work in. Getting roles right is the foundation of how work is divided between admins, managers, agents, and analysts.
The page has two tabs at the top:
Roles - The list of roles configured for your workspace, with the people in each.
Users - A flat list of every user in the org alongside the roles they belong to, so admins can audit and reassign role membership without drilling into each role.
The roles list
The default view is the roles list, organized as a four-column layout:
Role
The role's name. System roles (e.g. Super Admin, Manager) carry a "System role" badge with a lock icon and cannot be deleted.
Users
A small avatar stack of members in the role, with a +N count when more than three members exist.
Queues
The number of queues this role has access to.
Description
The role's freeform description, with a chevron that opens the role's detail page.
Clicking any row opens the role's detail page where admins edit its permissions, queue access, and member list.
Creating a role
Two buttons in the top-right of the page give you two creation paths:
Create from Template - Opens a modal of pre-built role templates (e.g. Agent, Analyst, Read-only viewer) so admins can spin up a sensible role in one click and customize from there. This is the recommended starting point.
Create New Role - Opens a blank role-creation modal for admins who want to define everything from scratch.
If your workspace currently has only system roles (Super Admin and Manager), the page surfaces the template cards directly so the next step is obvious instead of starting with an empty list.
Queues
The Queues page configures the queues that group and route incoming actions to the right teams. Every action in Sift lives in exactly one queue, and queues are the unit of access control for agents — which queue a person can see is determined by their role.
The page is a single drag-and-drop table with four columns:
Queue
The queue's name.
No. of items
The number of actions currently waiting in the queue.
Created
When the queue was created.
Creating a queue
The Create new queue button in the top-right opens a small modal where you name the queue. Once created, the queue is empty until actions flow into it via workflows, action rules, or manual routing.
Queue detail page
Clicking a queue opens its dedicated page. There you'll find a few cards:
Overview - Headline counts and recent activity for the queue.
Access - Which roles can see and act on items in this queue. Adding a role here is the most common way to grant a team access to a body of work.
AI Review - Configures how Sift's AI reviews actions in this queue (for example whether to require AI review before sending replies).
Rename - A modal entry-point to change the queue name.
Clear unassigned tickets - A safe way to wipe items that haven't been picked up.
Delete queue - A destructive action with a confirmation dialog.
Agent Identities
The Agent Identities page links the platform usernames your team uses on native apps (Discord and others) to your Sift organization, so messages those teammates send on those platforms are correctly attributed as agent activity in analytics, metrics, and workflows.
Without identities, a message posted by a support engineer on Discord would appear as just another community member. With identities configured, the same message is recognized as an agent reply and counts against your team's response-time and CSAT metrics.
Agent Roles
The first major section. Pick a connected platform (currently Discord) and a role on that platform, and Sift will treat every member of that role as an agent. New users who later receive the role are synced automatically - you don't have to come back to add them.
The card has two parts:
Existing role mappings - A list of role-to-agent mappings already in place, with the platform icon, the role name, the platform's display name, and the count of agents currently mapped from that role. Each row has a remove (trash) action.
Add role form - A platform select, a role select, and an Add agent role button. The role select is populated from the platform once you choose it, and roles already mapped are hidden so you can't add the same role twice.
This section only appears when at least one of the supported role-based platforms is connected.
Manual Identities
The second section is for adding individual platform usernames as agent identities - useful when a teammate doesn't fit a role on the platform, or for platforms that don't expose roles.
The card has three controls:
Platform - A select listing every connected platform that supports identity attribution.
Agent - A select of org members; pick which Sift teammate this platform identity belongs to.
Platform username - A combobox that searches the chosen platform for users matching what you type. As you type, Sift surfaces matching accounts so you can pick from a list, or fall back to "Use @username" to add a custom value manually if the user isn't found.
A blue Add identity button at the bottom commits the mapping.
All Agent Identities
The third section is the complete inventory of identities currently configured for the org, grouped by platform into collapsible sections. Each platform group shows its logo, name, and a count badge of identities, with a colored left border that matches the platform's brand color.
Inside each group, every identity row shows the platform username, an optional role badge, and the linked teammate's display name when available. Hovering a row reveals a remove button.
If no identities are configured yet, an empty state explains how to add the first one.
Workflows
The Workflows page is the configuration surface for the automations that drive how content moves through Sift after it's ingested - classifying records, assigning them to queues and agents, applying tags, sending notifications, and triggering AI replies. A workflow is a visual flow of steps that runs against incoming events (or on a schedule), and this page is where admins manage the library of workflows in the workspace.
The page is split into two tabs at the top: Workflows and Workflow Triggers.
The default tab. The view is a single drag-and-drop table of every workflow in the workspace:
Name
The workflow's name.
Description
A short freeform description of what the workflow does.
Created
When the workflow was created.
Last updated
When it was most recently edited.
Workflow Triggers tab
The second tab manages scheduled and search-based triggers - workflows that should run automatically when a saved search's criteria match, on a recurring cadence rather than reactively against incoming events.
Saved Responses
The Saved Responses page manages the library of reusable reply templates available to your team. When agents are working in the inbox, they can drop a saved response into a reply with a single click, so common answers - refund policies, escalation messages, standard apologies - are typed once and reused everywhere. Workflows can also reference saved responses for AI-assisted reply suggestions.
The top of the page shows the page title alongside a counter of how many responses currently exist in the workspace, and how many are visible after filtering. A + New response button in the top-right opens the create dialog.
Filtering and search
A filter bar below the header narrows the visible responses by:
Search - Free-text filter against the title and body of the response.
Type - A toggle group with All, Shared, and Personal. Shared responses are visible to the whole org; personal ones are only visible to the user who created them. Each option shows a count of matching responses.
Sort - Three options: Recent (most recently used), Alphabetical, and Created (most recently created).
Action Rules
The Action Rules page configures the operational rules that govern how actions and conversations behave inside Sift — limits on tickets per user, auto-close timers, thread locking, and the customer feedback (CSAT) survey that fires when conversations close. These are the org-wide policies that keep your queue manageable.
The page has two tabs at the top: Support Settings and Feedback & CSAT.
Support Settings
The first tab. Three cards configure the operational behavior of actions and threads.
Maximum Ticket Limit
Controls the maximum number of tickets a single user (customer) can have open at once. The card has a numeric input, with a hint that 0 means unlimited, and an Update button to save.
My Assigned Actions
A self-service utility that shows how many actions are currently assigned to you and lets you bulk-unassign them so they become available for other agents. The action surfaces a confirmation dialog explaining how many actions will be released back to the queue.
Close Settings
The most substantive card on the tab. Configure time-related rules for actions and threads:
Auto-Close Actions - A duration picker (hours or days) for how long an action can be inactive before Sift auto-closes it. A Close Inactive Threads Now button is provided so admins can run a one-time pass against the configured threshold without waiting for the next automatic run.
Thread Lock - A duration picker for how long after a thread is closed before Sift locks it from further replies. Locked threads stay visible but can't be reopened or replied to.
Feedback & CSAT
The second tab configures the customer satisfaction (CSAT) survey Sift sends when conversations close, and the close reasons that drive when surveys fire.
Two-Step CSAT Messages
Sift uses a two-step CSAT survey across all platforms: first a rating prompt, then an optional follow-up for written feedback. Two textareas let admins customize the wording:
Rating message - The prompt asking how satisfied the customer was with the resolution. Defaults to "How satisfied are you with the resolution provided here?"
Feedback message - The follow-up prompt for additional comments. Defaults to "Do you have any additional comments or feedback about your experience?"
Close Reasons
A managed list of the reasons your team uses when closing a conversation - for example Resolved, Spam, Duplicate, Customer disengaged. For each close reason, admins can:
Edit the reason's name.
Toggle whether closing with that reason triggers a CSAT survey (so spammy or disengaged closes don't ask for feedback).
Reorder, add new reasons, or delete unused ones.
A text field with placeholder "Enter new close reason..." and an add button at the bottom of the card extends the list.
Last updated