TATER SecurityTATER Ops

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.

Signing in

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.

  • Workspace - Dashboard (default landing page), Tasks (full list with KPIs and filters), My Tasks (assigned to you)
  • Configure - Task Catalog (reusable task definitions), Task Templates (recurring auto-generated tasks), Script Schedules (scheduled script execution with drift detection)
  • Knowledge - Business Docs, Document Reviews, Surveys, Policies, Documentation, TATERpedia (browse + native inline editing; the same records are shared with TATER Security and TATER Manage). See the Surveys and Document Reviews guides.
  • Reference - TATER Security ↗, Help & Docs ↗
  • Administration (SuperAdmin only) - deep-links to TATER Manage

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), 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.).

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.

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 including the Administration nav block (deep-links into TATER Manage)

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.