Back to Incident & Issue Reporting

Developer Handover Pack

Everything needed to build the automation from scratch: current state, full agent specs, data flow, and the build stack.

4 pagesPDF · Technical
FS-DOC-04Technical

Developer Handover Pack

Incident and Issue Reporting Automation

[YourCompany.com] · Operations Department · Prepared by FullSpec · [Today's Date]

This document is the primary technical reference for the FullSpec team building the Incident and Issue Reporting automation. It covers the full current-state process map, both agent specifications with IO contracts and build constraints, the end-to-end data flow, and the recommended build stack. Everything needed to configure, connect, and test the two-agent workflow is contained here. The process owner's role during build is limited to approving the severity rubric and confirming tool access. FullSpec handles all configuration, integration, and testing.

01Process snapshot

Step
Name
Description
1
Employee Identifies and Notifies
Any staff member notices a problem and reports it verbally, by email, or in a Slack channel. No standard format or required fields. Time cost: 5 min.
2
Manager Reads and Acknowledges
Operations Manager reads the report and sends a brief acknowledgement to the reporter, often hours after the original report. Time cost: 8 min.
3
Manually Enter Into Incident Log
BOTTLENECK. Manager re-types key details from email or chat into the shared incident spreadsheet. Missing fields are left blank and chased separately. Time cost: 12 min.
4
Assess Severity and Categorise
BOTTLENECK. Manager reads the description and assigns a severity level and category by personal judgement. No scoring rubric exists. Time cost: 10 min.
5
Identify and Notify Responsible Owner
Manager decides who should own the incident and sends a direct Slack message or email with context and next steps. Time cost: 8 min.
6
Set Resolution Deadline
A deadline is communicated verbally or by message. Rarely added to a shared calendar or tracked in the incident log. Time cost: 5 min.
7
Chase Status Updates Manually
BOTTLENECK. Manager follows up repeatedly with the assigned owner if no update is received. Repeats multiple times per incident. Time cost: 15 min.
8
Update Incident Log With Progress
When an update is received, the manager manually edits the spreadsheet row to reflect current status and any notes. Time cost: 7 min.
9
Confirm Resolution and Close Record
Once the owner reports the issue fixed, the manager marks it closed in the spreadsheet and notifies the original reporter. Time cost: 8 min.
10
File Supporting Documents
Photos, attachments, and investigation notes are saved to a shared folder, often with inconsistent naming conventions. Time cost: 6 min.
Time cost summary: Total manual time per incident cycle is 84 minutes. At approximately 40 incidents per month (~42 this month), that equals roughly 58.8 hours of manager time per month, or 6.5 hours per week. Steps 2, 3, 4, 5, 6, and 7 are replaced by automation: the Incident Triage Agent eliminates steps 3 and 4; the Notification and Escalation Agent eliminates steps 2, 5, 6, and 7. Post-automation, the manager's hands-on time per incident drops to approximately 12 minutes, covering review of escalated records and final closure confirmation only.
Developer Handover PackPage 1 of 4
FS-DOC-04Technical

02Agent specifications

Incident Triage Agent

The Incident Triage Agent is the first automated step in the workflow. It fires on every new Google Form submission, reads the full response payload, and applies the agreed severity scoring rubric to produce a structured classification record. The agent assigns a numeric severity score (1 to 5), maps the incident to one of the defined category labels, determines the appropriate owner based on a routing table, and calculates the resolution deadline from severity-tier SLA rules. It then writes a complete incident row to the Google Sheets log and creates a corresponding structured page in Notion. If any required field is missing from the form response, the agent flags the record for human review rather than proceeding with partial data. This agent is Moderate complexity and is estimated at 14 hours to build and test.

Trigger
New Google Form response appended to the connected Google Sheet (row-added event via Sheets API polling or webhook, depending on platform capability).
Tools
Google Forms (intake), Google Sheets (log write), Notion (page creation).
Replaces steps
Step 3 (manual log entry) and Step 4 (severity assessment and categorisation).
Estimated build
14 hours. Complexity: Moderate.
// Input: Google Form response payload
form_response_id       : string   // unique Form submission ID
submitted_at           : ISO8601  // timestamp of submission
reporter_email         : string   // submitting staff member email
incident_description   : string   // free-text description field
incident_location      : string   // site or system identifier
reporter_severity_hint : enum     // staff-selected: Low | Medium | High | Critical
category_hint          : enum     // staff-selected category from Form dropdown
attachments            : array    // optional photo or file URLs from Forms upload

// Output: Classified incident record written to Sheets + Notion
incident_id            : string   // auto-generated: INC-YYYYMMDD-NNN
severity_score         : integer  // 1-5 from rubric evaluation
severity_label         : enum     // Low | Medium | High | Critical
category               : string   // confirmed category label from rubric map
assigned_owner_email   : string   // looked up from owner routing table
assigned_owner_slack   : string   // Slack member ID for owner
resolution_deadline    : ISO8601  // calculated from severity SLA rules
triage_status          : enum     // Auto-classified | Flagged-for-review
notion_page_id         : string   // ID of created Notion page
sheets_row_index       : integer  // row number in incident log sheet

// On flagged-for-review: incomplete or ambiguous form response
flag_reason            : string   // e.g. 'missing incident_location'
flag_notified_to       : string   // operations manager email
  • Google Forms must be configured with all required fields marked mandatory except attachments. The Sheets destination tab must be the live response sheet linked directly to the Form; do not use a copied or imported sheet.
  • The severity scoring rubric must be finalised and approved by the operations manager before this agent is configured. The rubric maps keyword patterns in incident_description plus reporter_severity_hint to a numeric score. Build cannot proceed on this agent without the signed-off rubric document.
  • The owner routing table must be stored in a dedicated Sheets tab (named 'OwnerRouting') with columns: category, severity_label, owner_email, owner_slack_id. The agent reads this tab on each run. Changes to routing are made by editing this tab, not by modifying agent logic.
  • Notion integration requires a Notion internal integration token with insert access to the target database. The database must have the following properties pre-created: Incident ID (title), Severity (select), Category (select), Reporter Email (email), Assigned Owner (person), Deadline (date), Status (select: Open | In Progress | Resolved), Description (text), Attachments (files). Confirm database ID before build.
  • Dedupe behaviour: if a form_response_id already exists in the Sheets log (column: Form Response ID), the agent must skip processing and log a warning to the error log. This prevents double-writes on platform retry events.
  • Fallback for missing required fields: write a partial row to Sheets with triage_status set to 'Flagged-for-review', send an alert email to the operations manager email address (stored in platform credentials store as OPS_MANAGER_EMAIL), and halt further processing for that record until manually reviewed.
  • The Notion page template for each category must be pre-built before this agent is activated. Confirm template page IDs are stored in a config tab ('NotionTemplates') in the incident log Sheets file.
  • Google Sheets API tier required: standard read/write access. Confirm the service account has Editor access to the incident log spreadsheet. Notion API version: 2022-06-28 or later.
Notification and Escalation Agent

The Notification and Escalation Agent fires immediately after the Triage Agent writes a classified incident record to Sheets and Notion. It handles all outbound communication for the incident: a Slack direct message to the assigned owner with the incident summary, severity, deadline, and Notion page link; a Gmail acknowledgement to the original reporter confirming receipt, incident ID, assigned owner, and expected resolution window; and, if the severity_label is High or Critical, a PagerDuty incident alert to the on-call manager. The agent also schedules reminder messages to the assigned owner at configurable intervals (default: 24 hours before deadline and again at deadline) until the incident status in Sheets is updated to Resolved. This agent is Moderate complexity and is estimated at 14 hours to build, test, and configure reminder scheduling.

Trigger
A new classified incident row is written to the Google Sheets incident log by the Triage Agent (triage_status is Auto-classified or Flagged-for-review where owner is still assigned).
Tools
Slack (owner DM and reminder messages), Gmail (reporter acknowledgement), PagerDuty (high-severity escalation alert).
Replaces steps
Step 2 (manager acknowledgement), Step 5 (owner notification), Step 6 (deadline communication), and Step 7 (manual status chasing).
Estimated build
14 hours. Complexity: Moderate.
// Input: Classified incident record from Triage Agent output
incident_id            : string   // e.g. INC-20240617-001
severity_label         : enum     // Low | Medium | High | Critical
severity_score         : integer  // 1-5
category               : string   // confirmed category label
incident_description   : string   // original free-text description
reporter_email         : string   // for Gmail acknowledgement
assigned_owner_email   : string   // for Gmail CC and Slack DM
assigned_owner_slack   : string   // Slack member ID
resolution_deadline    : ISO8601  // for deadline comms and reminder scheduling
notion_page_url        : string   // link embedded in Slack and Gmail messages
triage_status          : enum     // Auto-classified | Flagged-for-review

// Output: Outbound notifications dispatched
slack_message_ts       : string   // Slack message timestamp (for thread replies)
gmail_message_id       : string   // Gmail sent message ID for audit trail
pagerduty_incident_id  : string   // PD incident ID (High/Critical only, else null)
reminder_schedule_id   : string   // scheduled job ID for follow-up nudges
notifications_log_row  : integer  // row written to 'NotificationsLog' Sheets tab

// On approval / resolution check (reminder loop)
sheets_status_check    : enum     // Open | In Progress | Resolved
reminder_sent_count    : integer  // increments per reminder dispatched
reminder_cancelled_at  : ISO8601  // timestamp when status becomes Resolved
  • Slack integration requires a Slack bot token (xoxb-) with scopes: chat:write, users:read, users:read.email. The bot must be installed to the workspace and invited to any channels used for broadcast notifications. Owner DMs are sent via users.lookupByEmail to resolve assigned_owner_slack from assigned_owner_email if the Sheets value is missing.
  • Gmail integration uses a service account with domain-wide delegation or an OAuth 2.0 token for the sending address. The sending address must be confirmed before build and stored in the credentials store as GMAIL_SENDER_ADDRESS. All outbound Gmail messages must include the incident_id in the subject line for auditability.
  • PagerDuty integration requires a PagerDuty Events API v2 routing key (integration key) for the target escalation service. The routing key must be stored in the credentials store as PAGERDUTY_ROUTING_KEY. PagerDuty alerts are fired only when severity_label is High or Critical. Confirm the severity threshold with the operations manager before build: the default is score 4 or 5 on the 1-5 rubric.
  • PagerDuty alert fatigue is a documented risk for small teams. The default threshold (score 4+) should be confirmed in writing before go-live. Overly sensitive thresholds must be avoided. Include a note in the config tab ('AgentConfig' in Sheets) so the operations manager can request threshold changes without a code change.
  • Reminder scheduling: the agent must check the incident's Sheets status column at each reminder interval. If status is Resolved, cancel remaining reminders. If status is still Open or In Progress, send the Slack reminder to assigned_owner_slack and increment reminder_sent_count. Maximum reminder count before escalating to operations manager: 3 (configurable via AgentConfig tab).
  • The 'NotificationsLog' tab in the incident log Sheets file must be created before this agent is activated. Columns required: Incident ID, Notification Type (Slack/Gmail/PagerDuty/Reminder), Sent At, Recipient, Status (Sent/Failed).
  • Fallback for Slack DM failure (e.g. user not found): send the owner notification via Gmail to assigned_owner_email and log the Slack failure to the error log. Do not silently drop the notification.
  • Gmail acknowledgement template must be reviewed and approved by the operations manager before activation. Store the approved template text in the 'EmailTemplates' Sheets tab, keyed by notification type.
Developer Handover PackPage 2 of 4
FS-DOC-04Technical

03End-to-end data flow

Full trigger-to-output data flow with field names at each agent boundary. All field names match the Sheets column headers and Notion property names exactly.
// ============================================================
// INCIDENT AND ISSUE REPORTING: END-TO-END DATA FLOW
// ============================================================

// --- TRIGGER ---
// Staff member submits Google Form
TRIGGER: Google Form submission
  -> form_response_id     : string   // e.g. 'ACvB...' (Forms internal ID)
  -> submitted_at         : ISO8601  // e.g. '2024-06-17T09:14:33Z'
  -> reporter_email       : string   // e.g. 'jane.smith@yourcompany.com'
  -> incident_description : string   // free-text, up to 2000 chars
  -> incident_location    : string   // e.g. 'Warehouse B - Loading Bay'
  -> reporter_severity_hint : enum   // Low | Medium | High | Critical
  -> category_hint        : enum     // Equipment | Safety | Service | Near-miss | Other
  -> attachments          : array    // [] or [Drive file URL, ...]

// --- AGENT HANDOFF 1: Form response to Incident Triage Agent ---
// Platform reads new row from connected Sheets response tab
// Field names map directly from Sheets column headers to agent input

AGENT: Incident Triage Agent
  INPUT:
    form_response_id, submitted_at, reporter_email,
    incident_description, incident_location,
    reporter_severity_hint, category_hint, attachments

  STEP 1: Dedupe check
    -> query Sheets column 'Form Response ID' for form_response_id
    -> if EXISTS: log warning to ErrorLog tab, HALT
    -> if NOT EXISTS: continue

  STEP 2: Validate required fields
    -> required: reporter_email, incident_description, incident_location
    -> if ANY missing:
         triage_status = 'Flagged-for-review'
         flag_reason   = 'Missing: [field_name]'
         write partial row to Sheets
         send alert to OPS_MANAGER_EMAIL
         HALT further processing

  STEP 3: Apply severity rubric
    -> score_from_keywords  : integer  // keyword match against rubric table
    -> score_from_hint      : integer  // reporter_severity_hint mapped to 1-5
    -> severity_score       = weighted_average(score_from_keywords, score_from_hint)
    -> severity_label       = rubric_tier_map[severity_score]
    //  1-2 = Low, 3 = Medium, 4 = High, 5 = Critical

  STEP 4: Assign category and owner
    -> category             : string  // confirmed from OwnerRouting tab lookup
    -> assigned_owner_email : string  // from OwnerRouting[category][severity_label]
    -> assigned_owner_slack : string  // from OwnerRouting[category][severity_label]
    -> resolution_deadline  : ISO8601 // submitted_at + SLA_hours[severity_label]
    //  Low=72h, Medium=48h, High=24h, Critical=4h (configurable via AgentConfig)

  STEP 5: Generate incident ID
    -> incident_id = 'INC-' + YYYYMMDD + '-' + zero_padded_sequence
    // Sequence sourced from Sheets row count on incident log tab

  STEP 6: Write to Google Sheets incident log
    -> target tab: 'IncidentLog'
    -> columns written:
         incident_id, form_response_id, submitted_at, reporter_email,
         incident_description, incident_location, category,
         severity_score, severity_label, assigned_owner_email,
         resolution_deadline, triage_status, notion_page_id (pending)

  STEP 7: Create Notion incident page
    -> template page ID from NotionTemplates tab, keyed by category
    -> properties written:
         'Incident ID' (title)   = incident_id
         'Severity'   (select)   = severity_label
         'Category'   (select)   = category
         'Reporter Email' (email)= reporter_email
         'Assigned Owner' (person)= resolved from assigned_owner_email
         'Deadline'   (date)     = resolution_deadline
         'Status'     (select)   = 'Open'
         'Description' (text)    = incident_description
         'Attachments' (files)   = attachments
    -> notion_page_id, notion_page_url returned
    -> update Sheets row: notion_page_id = notion_page_id

  OUTPUT: incident_id, severity_score, severity_label, category,
          assigned_owner_email, assigned_owner_slack,
          resolution_deadline, triage_status, notion_page_id, notion_page_url

// --- AGENT HANDOFF 2: Triage Agent output to Notification and Escalation Agent ---
// Triggered by new row present in IncidentLog with triage_status set
// All Triage Agent output fields passed as input

AGENT: Notification and Escalation Agent
  INPUT:
    incident_id, severity_label, severity_score, category,
    incident_description, reporter_email, assigned_owner_email,
    assigned_owner_slack, resolution_deadline, notion_page_url, triage_status

  BRANCH A: Severity >= 4 (High or Critical)
    -> fire PagerDuty Events API v2
       routing_key    = PAGERDUTY_ROUTING_KEY (from credentials store)
       event_action   = 'trigger'
       payload.summary= incident_id + ': ' + severity_label + ' - ' + category
       payload.source = 'FullSpec Incident Automation'
       payload.custom_details.notion_url = notion_page_url
       payload.custom_details.reporter   = reporter_email
       payload.custom_details.deadline   = resolution_deadline
    -> capture pagerduty_incident_id from response

  BRANCH B: All incidents (parallel to Branch A where applicable)
    -> send Slack DM to assigned_owner_slack
       text: 'New incident assigned: [incident_id]\n
              Severity: [severity_label] | Category: [category]\n
              Deadline: [resolution_deadline]\n
              Record: [notion_page_url]'
    -> capture slack_message_ts

    -> send Gmail acknowledgement to reporter_email
       subject: 'Incident received: [incident_id]'
       body: template from EmailTemplates tab, key='reporter_ack'
       merge fields: incident_id, assigned_owner_email, resolution_deadline
    -> capture gmail_message_id

  STEP: Write to NotificationsLog tab
    -> row per notification type: Slack, Gmail, PagerDuty (if fired)
    -> fields: incident_id, notification_type, sent_at, recipient, status

  STEP: Schedule reminder loop
    -> reminder_1_at = resolution_deadline - 24h
    -> reminder_2_at = resolution_deadline
    -> at each scheduled time:
         check Sheets IncidentLog row status column
         if status == 'Resolved': cancel remaining reminders, HALT
         if status != 'Resolved': send Slack DM to assigned_owner_slack
           reminder text: 'Reminder: [incident_id] is due [resolution_deadline].'
           increment reminder_sent_count
         if reminder_sent_count >= 3: notify OPS_MANAGER_EMAIL via Gmail

  OUTPUT: slack_message_ts, gmail_message_id, pagerduty_incident_id,
          reminder_schedule_id, notifications_log_row

// --- RESOLUTION UPDATE (triggered externally) ---
// When owner updates Notion page Status to 'Resolved':
//   -> Notion webhook or polling detects status change
//   -> Update Sheets IncidentLog row:
//        status = 'Resolved'
//        resolved_at = ISO8601 timestamp
//        resolution_notes = Notion page resolution_notes field value
//   -> Cancel reminder schedule for incident_id
//   -> Optionally send Gmail to reporter_email confirming closure

// ============================================================
// END OF DATA FLOW
// ============================================================
Developer Handover PackPage 3 of 4
FS-DOC-04Technical

04Recommended build stack

Orchestration layer
A workflow automation platform configured with two discrete workflows, one per agent: 'Incident Triage Workflow' and 'Notification and Escalation Workflow'. Both workflows share a single credential store holding all API keys and tokens. No logic should be hardcoded in workflow nodes; all configurable values (SLA hours, severity thresholds, reminder counts, routing rules) must be externalised to the 'AgentConfig' tab in Google Sheets. This allows the operations manager to adjust behaviour without a build change.
Webhook configuration
The Triage Workflow is triggered by a polling mechanism on the Google Sheets response tab (checking for new rows at 1-minute intervals) or by a native Sheets webhook if the platform supports it. The Notification Workflow is triggered by the Triage Workflow completing successfully (chained execution). The resolution update step is triggered by a Notion webhook (page property change event on the 'Status' field) or a scheduled polling check every 15 minutes on open incident rows. Webhook endpoint URLs must be stored in the platform's environment config and rotated if credentials are cycled.
Templating approach
All outbound message content (Slack DM text, Gmail subject and body, PagerDuty alert summary) is defined in Sheets tabs ('EmailTemplates', 'SlackTemplates') rather than hardcoded in workflow nodes. Templates use double-bracket merge syntax (e.g. {{incident_id}}) consistent with the platform's built-in expression engine. The operations manager can edit templates in Sheets without touching the workflow. Template tab structure must be set up and reviewed before agent activation.
Error logging
All workflow errors, fallback events, and skipped records are written to an 'ErrorLog' tab in the incident log Google Sheets file. Columns: Timestamp, Workflow Name, Incident ID (where available), Error Type, Error Detail, Resolved (checkbox). A Slack alert is sent to the OPS_MANAGER_EMAIL owner's Slack ID whenever a new error row is written. Critical errors (Notion write failure, PagerDuty dispatch failure on a High/Critical incident) must also trigger a Gmail alert to support@gofullspec.com for FullSpec monitoring during the go-live period.
Testing approach
All integrations are configured and tested in sandbox mode first. Google Forms uses a duplicate test form connected to a 'IncidentLog_TEST' sheet. Notion uses a duplicate test database. Slack DMs are sent to a dedicated test user account. PagerDuty uses the sandbox event routing key. Gmail sends to an internal test address. No live credentials are used until the QA phase is complete and sign-off is received from the process owner.
Estimated total build time
Incident Triage Agent: 14 hours. Notification and Escalation Agent: 14 hours. Form and Sheets schema setup: 3 hours. Notion database and template setup: 2 hours. End-to-end integration testing and QA: 3 hours. Total: 36 hours. This matches the confirmed build effort in the project snapshot.
Pre-build blockers: Three items must be resolved before build begins. First, the severity scoring rubric must be approved in writing by the operations manager. Second, all tool access credentials (Google Workspace service account, Notion integration token, Slack bot token, PagerDuty routing key) must be provisioned and shared with the FullSpec team via the secure credentials handover process. Third, the owner routing table must be populated with at least one owner per category before the Triage Agent can be tested end-to-end. Build can begin on Form and Sheets setup while these are being finalised, but agent configuration cannot start until all three are confirmed.
Support and handover: Once the build is complete and QA is signed off, all workflow files, credential references, template tabs, and config tabs will be documented in a handover summary delivered by the FullSpec team. For ongoing issues or changes after go-live, contact support@gofullspec.com.
Developer Handover PackPage 4 of 4

More documents for this process

Every document generated for Incident & Issue Reporting.

Launch Plan
Operations · Owner
View
ROI and Business Case
Finance · Owner
View
Process Runbook / SOP
Operations · Owner
View
Integration and API Spec
Technical · Developer
View
Test and QA Plan
Quality · Developer
View