TATER Ops

Help desk and task management on the same TATER ecosystem. Same identity, same database, same theme - different surface.

What it is

TATER Ops is a sister application to TATER Security. It lives at ops.tatersecurity.com and serves operational task tracking - IT requests, sales engagements, document reviews, surveys & CSAT, scheduled recurring work. The TATER acronym for this product expands as Tasking, Assignment, Templating, Engagement & Reporting.

Use the same Microsoft Entra ID account you use for TATER Security. Both apps share the same Entra app registration (45afb90d-…) and MSAL session - sign in once via login.html, both apps recognize you. Multi-tenant audience: accounts in tatersecurity.com and any other tenant where the app is registered work.

Navigation is a two-part rail: an icon strip of modules down the far left, and a panel listing that module's pages. Eight modules ship, in rail order:

Workspace - Dashboard (default landing page), Tasks (full list with KPIs and filters), My Tasks (assigned to you), Org To-Dos, Reports, Devices, App Monitoring, Flow Monitor, Intune, Speed Test, Endpoint Profiles. The endpoint pages here are read-only operational views - authoring lives in TATER Manage.
Projects - Ops Projects (projects, milestones, and the tasks rolled up under them)
Vendor Ops - Vendor Complaints, Vendor Visits (the operational half of vendor management; the vendor register itself lives in TATER Security). See the Vendor posture guide.
Service Management - Service Catalog, Service Requests, CMDB, Service Portfolio, Major Incidents, Problem Management, Change Advisory Board, Release Management, On-Call, Status Page, Onboarding / Offboarding, License Approvals, Travel Approvals, Expenses, Opportunities. Most of these have their own guide, linked from the sections below.
Independence - Cycles & Reviews, Client Roster, My Attestation, Configuration. See the Independence Management guide.
Configure - Task Catalog (reusable task definitions), Task Templates (recurring auto-generated tasks), Workflows, SLAs, Script Library, Script Schedules (scheduled script execution with drift detection), Meetings, Outlook Calendar, Meeting Templates
Knowledge - Business Docs, Document Reviews, Surveys, Information Requests, Policies, Documentation, TATERpedia, Troubleshooting Guides (browse + native inline editing; the same records are shared with TATER Security and TATER Manage). See the Surveys and Document Reviews guides.
Settings - Settings, TATER Tips, Feedback

Above the rail, directly under the TATER Ops brand, sits the app switcher - a row of small buttons for TATER Security, TATER Ops (the current app, shown active), TATER Manage, My TATER, TATER Insights, and TATER Vault. That row, not a nav group, is how you move between the sister apps. Below it is a Search menu box that filters the nav across every module, and the first icon on the rail itself is a Favorites star that opens your starred items in My TATER.

Tasks

Every task carries: title, description (Markdown), category (IT / Sales / Engagement / Proposal / Booking / Lead / DocumentReview / Other), priority (Critical / High / Normal / Low), status (default lifecycle: Open / InProgress / OnHold / Closed / Cancelled, plus a parked Planned state for future-phase work), requester, contact, assignee, due date, and optional links to TATER Security entities. Tasks bound to a Process Profile follow that profile's lifecycle and field rules instead (ITIL Incident, NIST IR, etc.).

Planned (parked) tasks

Tasks for a future project-plan phase can sit in a dedicated Planned state - parked rather than active. A Planned task is held out of the active Ops queue and out of overdue math entirely, and is counted separately in milestone/project rollups (it doesn't drag % complete or flip a milestone to at-risk) - so you can build out a multi-phase plan without placeholder due dates.

Activation date and Activation trigger - structured fields recording when the task should go live and what event unparks it (e.g. "Phase 1 sign-off"), replacing free-text notes.
Activating is a single flip: set the task to Open or In Progress and the activation date is automatically applied as the due date, starting the task today.
Tasks created under a milestone that isn't Active yet default to Planned automatically.
Use the "Planned (parked)" status filter on the Ops queue to see everything parked; create_tasker_task/update_tasker_task accept planned + activationDate/activationTrigger for the MCP/automation path.

Cross-product linkage

The most distinctive feature: every task can link to a specific TATER Security record. Click + Task in Ops on a control / risk / audit / vendor / policy / wiki / config-doc detail panel in TATER Security - Ops opens with the create-modal pre-filled with the linked entity. From the TATER side, the same panel shows 📋 N open tasks when there are linked tasks.

Comments

Every task has a comments thread powered by the same Comments API used by TATER controls. Comments are auditable, MCP-visible, and appear in the platform-wide Activity Log.

One Teams thread per ticket (threaded task cards)

By default, Teams notifications go out via an Incoming Webhook — which can only create new channel posts, so a busy email conversation produces one post per comment. For a clean channel, switch to threaded task cards: add the TATER bot to your team, then type @TATER register channel in the target channel. From then on each new ticket posts ONE card (a thread root) and every comment — email replies, web comments, MCP notes, user-action responses — lands as a reply inside that ticket's thread. Registration status (and an Unregister link) shows in TATER Manage → Task Notifications; the webhook remains as an automatic fallback if a bot post ever fails.

Private & shared channels: Microsoft Teams does not support bots in private or shared channels, so threaded cards aren't possible there — only a flat webhook (created from inside that channel) can post. To keep a private channel from being flooded with one card per comment, set Comment cards on the webhook (Manage → Task Notifications):

One card per comment — the original behavior.
Throttle (recommended for private channels) — at most one comment card per ticket per window (default 30 min); suppressed replies are folded into a “+N earlier replies” note on the next card.
Off — no comment cards at all; the channel gets new-ticket cards only. Assignees still get email / 1:1 DM for every comment, and the full thread always lives on the ticket.

This setting affects only the flat webhook path — registered (bot-threaded) standard channels always thread regardless.

Asking the user to do something (✋ Ask user)

When the next step is on the requester's side ("I migrated your profile — please reboot and confirm sign-in works"), open the task and click ✋ Ask user. Describe what you've done so far (optional) and what the user must do. TATER then:

Puts the ticket OnHold and shows a "Waiting on the user" banner with a Withdraw request button.
Emails the requester a TATER-branded message from the ticket's shared mailbox with three one-click buttons — Complete - Success, Complete - Failure, Need Assistance — each opening a confirmation page with an optional comment box (two-step on purpose: Safe-Links scanners prefetch URLs, so a single-click-mutating link would be "clicked" by the scanner).
On response: the answer lands on the ticket as a comment, the hold lifts (OnHold → InProgress, or straight to Resolved if you ticked Auto-resolve on Success), and the assignee is notified through the per-assignee notification channels.

The email subject carries the [TATER-XXXX] tag, so a user who ignores the buttons and simply replies by email still threads into the ticket. Response links expire after 14 days and are single-use; one pending request per ticket. MCP agents can do the same via the request_user_action tool.

Who gets the email: by default the ticket's requester. On MCP on-behalf tickets — where the requester defaults to the tech's bound identity — the email automatically goes to the ticket's contact instead when the requester equals the creator and a different contactEmail is set; an explicit recipient override is also available (the recipient_email MCP parameter / recipientEmail on the REST body). Multi-line instructions render with their line breaks intact in the delivered email.

Managing pending requests: the ticket detail shows the pending ask; MCP agents can inspect and clear them with list_user_action_requests and cancel_user_action_request (cancelling restores the ticket to its pre-hold status and frees the one-pending-per-ticket slot for a re-ask).

Task Catalog

Reusable task definitions for common requests (e.g. "New employee onboarding - IT setup"). Click any catalog entry from the Tasks page to open the create modal pre-filled with that catalog's defaults (category, priority, assignee, description). SuperAdmin / Admin can add and edit catalog entries; everyone can use them.

Task Templates

Recurring task templates that auto-generate on a schedule. Cadences: daily, weekly (with day-of-week selector), monthly (with day-of-month). The cron job taskerTemplateScheduler runs at 06:00 UTC daily and generates tasks from active templates whose nextRunAt has passed.

Azure DevOps sync

When configured, TATER Ops tasks are mirrored to ADO as work items. Bi-directional:

Outbound: every task create/update fires (fire-and-forget) to ADO. Status transitions are mapped (Open/InProgress → To Do, Closed/Cancelled → Done). The ADO work item ID is stored on the task as an external ref so subsequent updates target the same item.
Inbound: configure an ADO Service Hook → POST to https://api.tatersecurity.com/api/integrations/ado/webhook with required headers x-tater-tenant-id, x-tater-organization-id, and x-tater-ado-secret. ADO state changes flow back to TATER Ops within seconds.

Configuration lives in TATER Manage → Connections → Azure DevOps Sync.

ITIL Process Profiles

Tasks bind to a TaskerProfile that drives field visibility, allowed status transitions, and SLA defaults from an industry standard. Five profiles seed by default (Basic, ITIL 4 Incident, ITIL 4 Service Request, ITIL 4 Problem, NIST SP 800-61 IR). Custom profiles are authorable via JSON. See ITIL Process Profiles guide.

Service Catalog (predefined requests)

ServiceNow-style catalog of predefined request types (Laptop / Software Install / Access Request / Password Reset / VPN / MFA Re-enrollment / Onboarding / Off-boarding / Software, Hardware, Network & Email issue reports / Shared Mailbox). 13 starter items ship via seed-defaults — issue-report items fulfill through the ITIL Incident profile; the rest use ITIL Service Request. Each item has a form schema, fulfillment profile, approval flag, owner team, ETA. Submissions auto-route to Tasker tasks with proper categorization. See Service Catalog Administration + the end-user submitting + tracking guide.

CMDB / Configuration Items

Proper Configuration Items (CIs) with 16 types, 10 typed relationships (auto-maintained inverses), and recursive impact analysis. Auto-discovers from fleet devices, cloud accounts, and active vendors. The CMDB is the inventory layer that other Ops modules (Major Incident, CAB, Service Portfolio) consult for impact rollup and conflict detection. See CMDB guide.

Major Incident workflow

Promote an Incident-class task to a Major Incident with bridge URL, incident commander, subscribers (email broadcast), affected CIs (CMDB lookup), status update log, and auto-created Post-Incident Review task with 14-day due date + 8-item checklist on resolve. See Major Incident guide.

Problem Management

ITIL Problem records: the root cause behind recurring or major incidents, tracked separately from the day-to-day tickets. Each problem carries a root cause, a workaround, the incidents it explains, and the CMDB configuration items it affects; publishing one as a Known Error puts it in the Known Error Database, where it is offered automatically to technicians working matching tickets. Lifecycle: Open → Investigating → Known Error → Resolved → Closed. See Problem Management guide.

CAB workflow on Change Requests

ITIL Change Enablement with Change Advisory Board (CAB) multi-approver voting, conflict detection against pending/approved changes (window-overlap / same-CI / same-control), change calendar, three change types (Standard / Normal / Emergency). See CAB workflow guide.

Release Management

Bundle CAB-approved Change Requests into coordinated deployments with rollout + rollback step lists, success criteria, deployment log (capped at 500 entries), and lifecycle status (planned → approved → scheduled → in-progress → deployed / rolled-back / cancelled) with auto-stamped timestamps. See Release Management guide.

Service Portfolio

Business-facing service view layered on CMDB. Services are CIs of type business-service or service that contain other CIs. Health rollup combines worst member CI status with active Major Incidents touching members (healthy / degraded / major-outage / maintenance / unknown). Executive-friendly. See Service Portfolio guide.

Meeting Documentation

Meeting Records with attendees, agenda, decisions, raw transcript (PDF/DOCX uploaded by you, parsed by your AI), and linked-artifact roll-up to tasks / change requests / business docs. MCP-first: your external LLM does all extraction. See Meeting Documentation guide.

Workflows + Scheduled Execution

TaskerWorkflows orchestrate parent + sequenced child tasks with dependsOn unlocking on close. OpsSchedules trigger recurring script execution against fleet devices or M365 tenants with drift detection between runs. See Workflow Automation + Scheduled Execution.

MCP integration (40+ Ops tools)

The Ops side of TATER exposes 40+ MCP tools across Catalog, CMDB, Major Incident, CAB, Release Management, Workflows, Schedules, Meetings, Profiles. Representative samples:

Tasks: list_tasker_tasks, create_tasker_task, update_tasker_task
Catalog: list_service_catalog, get_catalog_item, submit_catalog_request
CMDB: list_cis, get_ci, create_ci, relate_cis, get_ci_impact, discover_cis
Major Incident: declare_major_incident, post_major_incident_update, resolve_major_incident
CAB: create_cab_board, submit_change_to_cab, cab_vote, get_cab_queue
Release: create_release, transition_release_status, append_release_log

See MCP setup for the full tool catalog. All Ops-domain MCP writes audit-log with via:'mcp' (or via:'copilot' / via:'claude' based on User-Agent).

Permissions

Viewer - read tasks/catalog/templates
Auditor - create + update tasks
Admin - manage catalog and templates; soft-delete tasks
SuperAdmin - full access. Org and platform administration is not an Ops nav group: use the TATER Manage button in the app switcher at the top of the sidebar

Direct URL

Bookmark ops.tatersecurity.com. The app is also reachable at app.tatersecurity.com/ops.html. Either URL routes to the same SWA via the hostname-redirect script in TATER.html.