Assigning and working on requests

When an employee creates a request, it’s routed to a workspace based on the request type and your workspace routing configuration. Service requests are routed to the workspace mapped to the selected service catalog item, and incident catalog items are routed to the workspace mapped to that incident catalog. Workspace admins and supervisors can view new unassigned requests in the Requests tab under the Unassigned view and assign them to their teammates. Assignment dropdowns show live agent availability indicators: green for Available and white for Away, so admins and supervisors can see who is reachable before assigning work. Agents get notified via DM when a request is assigned to them.

Workspace admins and supervisors may also encounter requests created in additional workspaces when admins or agents raise requests into teams they work with directly. This broader workspace visibility helps teams route requests to the right workspace when they collaborate across teams.

If multiple eligible workspaces are available, admins can go to Settings > Enterprise AI > Configuration > Workspace routing (Deploy) and choose between Smart Routing, Smart Suggestion, and requester selection. In Smart Suggestion mode, Atom preselects the best workspace for a request or general incident and shows a dropdown so the employee can override the recommendation before submitting. Catalog-based service requests and catalog-based incidents are not affected by this routing mode and continue to use their catalog mappings.

Request views

Atomicwork categorizes request view filters into your request views and the workspace’s views for ease of access. In Atomicwork, requests have a 1:1 association with workspaces.

Your request views (Across workspaces)

These views sit under Inbox in the left navigation.

• Assigned to me. Atomicwork pulls up a list of all the requests assigned to you to work on when you click this view.

• Created by me. This view lists records you've created. Use the Requests tab for requests you've raised as a requester and the Changes tab for changes you created.

• Following. This view lists the requests and changes you follow, including ones you follow through an agent group.

• Mentions. This view lists requests and changes where you've been mentioned. Use the Changes tab to see changes where you are mentioned.

• Approvals. This is a list of all the requests where you've been added as an approver.

• Acknowledgements. If you're a workspace admin, this view lists major incident proposals waiting for you to approve or decline, with Pending and Completed tabs that work like Approvals. You get the same request in Slack or Microsoft Teams. See Major incident management.

Workspace views

Atomicwork groups requests, incidents, service requests, changes, and problems into workspaces so that teams don’t have to sort through requests they cannot handle to find the ones that need their attention. Changes in a workspace can include employee-raised changes when the underlying change template is enabled for employee requesters.

• Go to Your workspaces > [Workspace name] > Requests in the left navigation bar to pull up a list of requests.

You can view only the requests that are a part of the workspace you have access to. You can access the entire list of views by clicking [number of views] more. You can add filters and save the view as a custom view for all agents in your workspace to access. If you'd like to share a view with another agent, click the ... icon and click Copy link to view to get a shareable link. ​ Here is a full list of default views:

• Today. Use this view to keep track of all requests due today

• Unassigned. This is a view that supervisors and admins can use to assign requests to agents as they get created.

• High priority. With this view, you can view all the high and urgent priority requests created and associated with this workspace, no matter the current status of those requests.

• Service requests. This is a list of all the service requests raised by employees. Service requests are automatically routed to the workspaces that list the service that the request is linked to in its service catalog.

• All requests. This is a list of all the requests created and associated with this workspace.

• Incidents. All the incidents in the workspace.

• Trash. When you delete a request, it moves to the trash view. You can restore or delete trash requests forever if they don’t give you joy. Requests in the trash will be in read-only mode. You cannot add any new responses or replies to them.

You can also modify what attributes you'd like to be a part of your request list page from the display options (gear icon) on the list. Within a workspace, requests can be assigned to specific agent groups, which determine their visibility and handling permissions.

Board view

Service request and incident lists in a workspace can switch from a table to a Kanban board. Open the display options (gear icon) on a list and toggle between Table and Board. Atomicwork remembers your choice, along with your grouping, ordering and card setup, for each view.

• Group your board. Group by Status, Priority, Impact or Urgency, and each value becomes a column. Sub-group by a second field to add swimlanes, for example Status columns with Priority swimlanes.

• Arrange columns. Reorder columns by drag and drop, or sort them by the field's natural order, reverse order, or ticket count. You can hide empty columns or switch off specific values. Tickets without a value for the grouped field go in a No value lane.

• Move cards to update tickets. Dragging a card to another column updates that field on the ticket. If you drop a card into a closing status, Atomicwork prompts you for any mandatory-on-close fields first. Your permissions on the ticket still apply.

• Work from the board. The view's filters and sort apply to the board as they do to the table. Cards show the attributes you choose. You can multi-select cards for bulk actions, or click a card to open the ticket's details.

For example, during a daily stand-up you could group incidents by Status and sub-group by Priority. Each status becomes a column and each priority a swimlane, so the team can see urgent items stuck in Pending at a glance and drag tickets forward as they're discussed.

Agent groups

Admins can manage three types of groups:

• Open groups: Requests assigned to an Open group are available to all agents in a workspace. All agents can view these requests, be assigned to them, add replies and comments, or update attributes.

• Restricted groups: Requests assigned to a Restricted group are fully accessible only to agents within that group. Other agents in the workspace can view these requests but can only add private notes.

• Private groups: Requests assigned to a Private group are only accessible to agents within that group. Other agents in the workspace cannot view these requests.

When round-robin assignment is used for a group, agents marked Away are skipped automatically until they are Available. To learn how agents set their status, see Manage agent availability.

Request details layout

Requests, service requests, incidents, problems and changes share one detail page layout:

• Main column. The subject, description and requested service come first. Below them, the Comments, Activity and Associations tabs hold the conversation, the timeline and linked records. The reply box follows, with Reply and Note tabs.

• Status, Follow and the three-dot menu. Change the status from its dropdown, follow the request with Follow, and use the three-dot menu (⋮) for actions on the record itself, such as linking a request, converting, cloning, moving, printing and deleting it.

• Side panels. Details (requester, group, agent, priority, category and tags), AI usage, Approvals and, where relevant, Linked assets sit in collapsible panels. Each panel remembers whether you left it open or collapsed.

Send replies and add private notes

If you want to send a reply to the requester, open the request and select the Reply tab before typing out a message. Atom will send answers as updates to the requester as a DM. Requesters can respond to the DM, and their response will be synced to the request in Atomicwork.

Select the Note tab and type out a message visible only to other workspace operators to add a private note on a request. You can @mention users, AI Coworkers or agent groups in a private note if you'd like some input (we'll notify them for you). Mentioning someone also adds them as a follower of the request.

Send and set status

You can post a reply or private note and change the ticket's status in one step. Click the chevron next to Send to open Send and set as:, then select the status you want. The list shows every status the ticket can move to. This works for both Reply and Note on service requests, incidents, problems and changes.

If the status you pick needs mandatory-on-close fields, that form opens first. If you cancel the form, nothing is sent and your draft stays as it is. The activity timeline records the action as a single row, for example "added a private note and changed Status from Open to Pending".

Working on a request

• When you start working on a request, you need to make sure that the status of the request matches the solution progress and pause/let the SLA timer tick on. Atomicwork has seven default request statuses but you can add more to reflect your team's processes.

• You can change a status by clicking the value in the field and choosing a new status. If you just want to resolve the request, click the Mark resolved button and the request will be moved to the resolved stage.

• Keep abreast of all updates on a request by adding yourself as a follower to the request. Click Follow on the request. To add other users, AI Coworkers or agent groups as followers, click the followers icon next to it and pick them from one searchable list to make sure all stakeholders stay in the loop. If you're mentioned directly or through an agent group, the request shows up in your mentions and following views. All request updates will be sent to you (and other followers) by DM, and if you're involved both directly and through a group, you only get each notification once. You can remove yourself as a follower from the request.

• You can also catch up on all request updates by clicking the Activity tab in a request to view the request timeline.

• Add approvers to a request or setup a workflow for speedy resolutions

When you raise a request for yourself

When you raise a request, incident or service request for yourself and you aren't its assignee, Atomicwork treats you as a requester on that ticket:

• The create form shows only the fields visible to requesters.

• On your own ticket, you see the requester view. Private notes, agent panels, status and assignment controls, and the move, clone and delete options are hidden.

• You can reply publicly, track progress, cancel your request and rate the resolution.

These permissions are enforced server-side and apply the same way in Slack, Microsoft Teams, the employee portal and Atom. There are a few exceptions:

• If you're assigned to your own ticket, you keep your agent permissions on it.

• If you're a designated approver, you can still act on approvals.

• Problems and major incidents aren't affected.

Staying informed with notifications

Requesters can get updates on the status of requests they’ve raised by asking Atom. Atom will notify agents via Slack or MS Teams on updates to requests that are assigned to them and on pending journey tasks. This way you'll always be in the loop and can manage your tasks efficiently. You will be notified when:

• A request or incident is assigned to you

• A private note is added on a request you're handling

• You're tagged on a private note in a request not assigned to you

• The SLA for a request you're handling is breached or is about to be breached (depending on the SLA settings)

• A request assigned to you is approved or declined

Setting up workflows for request management

Workflows with defined triggers, conditions, and actions, can free your team from doing routine tasks and sending updates. Workflows can use tags as conditions and include actions to add tags to requests or incidents. For example, a workflow action that notifies the head of IT when a service request from a senior executive is reprioritized can help the IT team manage service delivery expectations and mitigate frustration. Only workspace admins can set up workflows.