Request conversation
Every request has a single conversation timeline that keeps the full story in one place—agent replies, internal notes, approvals, status/SLA updates, and workflow events. Messages sync to the requester’s original channel (Slack or Microsoft Teams) and to the Portal.
What you can do in the request conversation
Reply: send a public message to the requester in Slack/Teams and the Portal. Attach files, use @mentions, and preview before sending.
Internal note: add private context for agents/admins only. Great for handoffs, troubleshooting, and coaching.
Approval: request sign‑off from one or more approvers. Statuses (Pending, Approved, Rejected) are tracked in the timeline and the sidebar.
Message Templates: insert reusable answers with variables to personalize at scale.
Message reply box
Type selector (left): choose Reply, Internal note, or Approval.
Composer: supports attachments, mentions, emojis, and templates.
Preview: review before sending (public replies and approvals).
Replies
Channel aware: goes to the requester where they started (Slack/Teams), and to the Portal.
Files: upload documents, images, or links; everything is mirrored to the request.
Articles: access your entire knowledge base to share articles
Mentions: @colleagues to bring them in; they become participants and get notified.
Internal notes
Visibility: only agents/admins can see notes; requesters never do.
Uses: capture investigation steps, share context across shifts, or coach teammates.
Mentions: notify teammates without pinging the requester.
How it works: pick approver(s), add context (or use a template), and send. Approvers can act from Slack/Teams or the Portal—no extra license needed.
States: Pending → Approved/Rejected. All decisions are logged in the timeline with who, when, and any comment.
Templates: prefill the message and include dynamic variables (approval_link, requester.first_name, app.name, etc.).
Automate: trigger workflows on Approved/Rejected (e.g., change status, assign, kick off provisioning, notify requester).
Purpose: keep answers fast and consistent; update centrally when policy changes.
Variables: personalize with fields like requester.first_name, requester.manager, service.name, app.name, approval_link, and more.
Organization: group templates by team or service for easy discovery.
Access: choose templates from the composer; admins manage them in Settings.
Request details: status, assignee, service, priority, tags, SLA timers, Snooze/Resolve.
People info: requester profile (title, manager, department, location, contacts).
Integrations: quick actions to connected systems (e.g., Okta, Google/Azure, MDM) when available.
Context: related requests, assigned equipment, active apps.
Approvals: current approval(s) with state and actions.
Deep links: clicking people, devices, or apps opens their dedicated pages for full context.
Last updated