FS-DOC-03Operations
Process Runbook / SOP
Data Quality Monitoring
[YourCompany.com] · IT Department · Prepared by FullSpec · [Today's Date]
This runbook is the day-to-day operating guide for the Data Quality Monitoring automation. It tells your IT analyst and IT manager exactly what the system does on its own, what they need to do themselves, how to handle problems when they arise, and who to call if something goes wrong. FullSpec builds, tests, and launches the automation end to end. Your team owns the rules, the fixes, and the day-to-day operation after go-live.
01Process overview
The Data Quality Monitoring process runs a scheduled rules engine against your connected data sources every 24 hours, or immediately when a new import event is detected. Three agents work in sequence: the Data Check Agent queries PostgreSQL and Airtable, runs every configured quality rule, and scores each issue by severity. The Issue Routing and Notification Agent then creates Jira tickets for critical and high-severity findings and posts a formatted alert to your IT Slack channel. At the end of each week the Reporting and Metrics Agent pushes aggregated quality metrics to your Datadog dashboard. The only step that stays with your team is applying manual fixes to complex records that the automation has already identified and ticketed.
Process name
Data Quality Monitoring
Trigger
Daily schedule (every 24 hours) or immediate trigger when a new data import event is detected from a watched source
Final output
Jira tickets for actionable issues, a complete Airtable issue log with severity scores, a Slack alert to the IT channel, and a live Datadog dashboard updated weekly
Agents running
Data Check Agent, Issue Routing and Notification Agent, Reporting and Metrics Agent
Tools involved
PostgreSQL, Airtable, Jira, Slack, Datadog, Google Sheets
Weekly volume
Approximately 120 data check events per month (daily runs plus ad hoc import triggers)
Human checkpoint
IT Analyst reviews Jira tickets and applies manual fixes to complex records that cannot be corrected automatically
Process owner
IT Analyst (Jordan Reyes) with oversight from IT Manager (Sam Okafor)
Process Runbook / SOPPage 1 of 4
FS-DOC-03Operations
02Step-by-step: what happens and who acts
What you actually need to do: There is one human step in this entire process. After the automation detects issues, creates Jira tickets, and sends the Slack alert, the IT Analyst opens the relevant Jira ticket, reviews the flagged records, and applies any manual database corrections that require judgment or a direct SQL query. Everything else, including the daily checks, all logging, ticket creation, Slack notifications, and the weekly Datadog report, runs automatically without any action from your team.
Step
What happens
Who acts
Type
1
The daily schedule fires, or the platform detects a new data import event from a watched source system. No human input is needed to start the process.
Automation
Automated
2
The Data Check Agent connects to PostgreSQL and Airtable, pulls the latest records for all configured fields and tables, and holds them ready for rule evaluation.
Data Check Agent
Automated
3
The Data Check Agent runs the full quality ruleset against the pulled records, checking for null values, format mismatches, duplicates, numeric out-of-range figures, and any other configured conditions. Each issue is assigned a severity score of critical, high, moderate, or low based on the agreed scoring thresholds.
Data Check Agent
Automated
4
Every detected issue is written as a new row in the Airtable issues log, capturing the source table, field name, error type, affected row count, severity score, and a timestamp. This creates the permanent audit trail for the run.
Issue Routing and Notification Agent
Automated
5
For every issue scored as critical or high, the Issue Routing and Notification Agent creates a Jira ticket automatically. Each ticket is pre-filled with the issue detail, the severity score, the affected field and row count, and a direct link to the corresponding Airtable log entry.
Issue Routing and Notification Agent
Automated
6
A formatted Slack message is posted to the designated IT channel. The message lists the total issue count broken down by severity, names the top critical items, and includes direct links to the Jira tickets just created.
Issue Routing and Notification Agent
Automated
7
The IT Analyst opens the Jira tickets surfaced in the Slack alert, reviews the flagged records, and applies manual fixes to any complex issues requiring a direct SQL correction or judgment call. Simple issues such as trailing whitespace or null defaults may be corrected by the automation if pre-approved remediation rules are in place.
IT Analyst
Human
8
At the end of each week, after the final daily check completes, the Reporting and Metrics Agent reads the accumulated Airtable issue log data and pushes aggregated metrics to the Datadog dashboard. The IT Manager can view total issues found, severity breakdown, and resolution rate without any manual report compilation.
Reporting and Metrics Agent
Automated
Process Runbook / SOPPage 2 of 4
FS-DOC-03Operations
03Handling exceptions
Situation
What the system does
What you do
A required field is missing from a record entirely (null or empty value where a value is always expected)
The Data Check Agent flags the field as a null violation, assigns a severity score based on which downstream reports depend on that field, logs the issue to Airtable, and creates a Jira ticket if the severity is critical or high.
Open the Jira ticket, identify whether the missing value can be sourced from another field or system, apply the correction manually in PostgreSQL, and mark the ticket resolved once confirmed.
A duplicate record is detected in the same import batch or across two connected sources
The Data Check Agent identifies the duplicate key, flags both record references in the Airtable log with a duplicate error type, and creates a single Jira ticket linking both affected rows. A Slack alert is sent with the count of duplicates found in the run.
Review the two records in the source system to determine which is authoritative, delete or merge as appropriate, and close the Jira ticket with a note on which record was retained.
A data source table or field referenced in the ruleset no longer exists (schema change, renamed column, or deleted table)
The Data Check Agent logs a configuration error to Airtable, skips that specific rule for the run rather than failing the entire check, and posts a Slack alert flagging the missing field reference by name.
Contact FullSpec support at support@gofullspec.com to update the ruleset configuration. Do not edit the ruleset directly unless you have been trained to do so. The remaining rules continue to run normally in the meantime.
The IT Analyst does not act on a critical Jira ticket within 24 hours
The system does not automatically escalate, but the Datadog dashboard will show the ticket as open and the issue as unresolved in the weekly metrics. The Airtable log entry remains open and will appear in the next weekly Slack summary.
The IT Manager (Sam Okafor) should review the Datadog dashboard daily for any critical open tickets that have aged past 24 hours and follow up with the analyst directly. If the ticket is blocked, note the blocker in the Jira ticket and adjust priority as needed.
A connected external tool is unavailable (Jira or Slack is down or returns an error at notification time)
The automation platform retries the failed step up to three times with a five-minute gap between attempts. If all retries fail, the issue remains logged in Airtable and the error is written to the automation platform error log. No data is lost.
Check the error log in the automation platform dashboard. If the tool outage is confirmed, wait for the service to recover and manually trigger a re-run of the notification step, or post the Slack summary manually from the Airtable log until the connection is restored. Contact support@gofullspec.com if the error persists after the tool recovers.
The same data source fails the same quality rule repeatedly across multiple runs (recurring violation)
Each run produces a new Airtable log entry and a new Jira ticket for the recurring issue. The Datadog dashboard will show the same error type increasing in count across the weekly metrics, making the pattern visible.
Review the Datadog trend data to identify the recurring pattern. Investigate whether the source system has a systematic export or formatting problem. If the issue reflects a legitimate data format change, contact support@gofullspec.com to update the relevant rule so the ruleset stays accurate.
04Who to contact and when
Fill in once your team is confirmed. Add the names and contact details for each role before go-live so everyone knows who to reach and how. The FullSpec rows are fixed and do not change.
Role
Name
How to reach them
IT Analyst (day-to-day process owner)
Jordan Reyes
[Rep email]
IT Manager (escalation and threshold approvals)
Sam Okafor
[Rep email]
Ops Manager (stakeholder, dashboard consumer)
Priya Nair
[Rep email]
Process owner backup (covers analyst absence)
[Your name]
[Rep email]
FullSpec builder (build and configuration changes)
FullSpec Team
support@gofullspec.com
FullSpec support (errors, outages, urgent issues)
FullSpec Support
support@gofullspec.com
For anything that requires a change to the quality ruleset, the scoring thresholds, or the tool connections, always contact FullSpec at support@gofullspec.com first. Changes to the rules engine made outside of a controlled update can cause historical Airtable trend data to become unreliable and may produce false alerts or missed detections until reconfigured.
Process Runbook / SOPPage 3 of 4
FS-DOC-03Operations
05Ongoing maintenance
Whenever a data source schema changes (new columns, renamed fields, deleted tables)
Notify FullSpec at support@gofullspec.com before the schema change goes live if possible, or immediately after. The ruleset configuration must be updated to reflect the new field names or table structure before the next scheduled run, otherwise the affected checks will skip silently.
IT Analyst to flag the change; FullSpec to update the configuration
Whenever Slack message templates or Jira ticket formats need updating (new fields, changed channel, updated ticket type)
Submit the required changes to support@gofullspec.com with the old and new values clearly stated. Do not edit notification templates directly in the automation platform without guidance, as formatting errors can cause the Slack post or Jira creation to fail.
IT Analyst or IT Manager to request; FullSpec to apply
Monthly spot-check (every month, first week)
Open the Airtable issues log and review the last 30 days of entries. Confirm that issue counts look consistent with expectations and that no rule has produced zero results for the full month without a clear reason. A rule that never fires may indicate a configuration problem rather than a perfectly clean data source.
IT Analyst
Weekly error-log review (every Monday morning)
Open the automation platform error log and scan for any failed steps, skipped rules, or connection timeouts from the previous week. If any errors are present, check whether the affected runs completed fully or partially, and contact support@gofullspec.com if the cause is not obvious.
IT Analyst
When a team member joins, leaves, or changes role
Update the contact table in this runbook with the new name and email. If the departing person was the Jira ticket assignee or the Slack channel admin, update those settings in Jira and Slack directly. Notify FullSpec if any service account credentials or notification routing needs to change.
IT Manager
Quarterly volume and threshold review (every three months)
Review the Datadog dashboard trend data for the quarter. Check whether severity thresholds still reflect business priorities: a field that was low priority three months ago may now feed a critical report. Bring any proposed threshold changes to the IT Manager for approval before submitting to FullSpec for implementation.
IT Manager, with IT Analyst input; FullSpec to apply approved changes
The most common maintenance issue for this process is a silent rule skip caused by a schema change in PostgreSQL that nobody flagged before the next check run. When a table or column name changes in the source database, the Data Check Agent cannot match its configured rule to the new structure and will skip that rule rather than error loudly. The Airtable log will simply have no entries for that check, which can look like a clean result. Always notify FullSpec before or immediately after any schema change, and cross-check monthly that every configured rule is producing results.
Process Runbook / SOPPage 4 of 4