Back to Internal Knowledge Base Management

Integration and API Spec

The reference during the build: every tool connection, auth scope, field mapping, and error-handling rule.

4 pagesPDF · Technical
FS-DOC-05Technical

Integration and API Spec

Internal Knowledge Base Management

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

This document defines the exact integration requirements, authentication details, field mappings, orchestration layout, and error handling behaviour for the Internal Knowledge Base Management automation. It is written for the FullSpec build team and covers every tool connection needed across both agents. All credential values must be stored in the shared credential store and never hardcoded. Sandbox connections must be validated before any production credentials are applied.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agent(s)
Google Forms
Structured intake trigger: receives content requests and article flags from staff
OAuth 2.0 (Google Workspace)
Free (Google account required)
Agent 1 (Knowledge Triage)
Notion
Knowledge base and article task database: task creation, status tracking, publishing, and archiving
OAuth 2.0 / Internal Integration Token
Plus ($16/month) or above for API access
Agent 1, Agent 2 (both agents)
Google Docs
Article drafting and inline review: source of draft content for triage and review routing
OAuth 2.0 (Google Workspace)
Free (Google account required)
Agent 1, Agent 2 (both agents)
Slack
Owner notifications, reviewer alerts, team announcements, and scheduled review reminders
OAuth 2.0 (Slack app)
Pro ($8/month) for DM and channel API access
Agent 2 (Review and Publish Coordinator)
Loom
Screen recordings embedded in how-to articles; read-only link retrieval for metadata inclusion
API key (Bearer token)
Starter ($12/month)
Agent 1 (read link metadata on intake)
Automation platform
Orchestration layer: hosts both agent workflows, manages triggers, credential store, retry logic, and inter-agent data passing
Internal (platform-managed)
Paid tier supporting webhook listeners and scheduled triggers ($29/month)
All agents
Before you connect anything: create a sandbox or test workspace for every tool listed above and validate all connection flows against test data before applying production credentials. For Notion, use a duplicate test database. For Slack, use a private test channel. For Google Forms, use a staging form. No production tokens should be entered into the credential store until sandbox validation passes for that tool.
Integration and API SpecPage 1 of 4
FS-DOC-05Technical

02Per-tool integration detail

Google Forms

Acts as the automation entry point. Every new form response triggers the Knowledge Triage Agent workflow. The form must be structured with fixed field names so the orchestration layer can parse responses reliably.

Auth method
OAuth 2.0 via Google Workspace. The service account or connected Google user must have read access to the target form and its response spreadsheet.
Required scopes
https://www.googleapis.com/auth/forms.body.readonly | https://www.googleapis.com/auth/forms.responses.readonly | https://www.googleapis.com/auth/spreadsheets.readonly (if responses are mirrored to a linked Sheet)
Webhook / trigger setup
Google Forms does not natively emit webhooks. The orchestration layer must poll the Forms API at a maximum interval of 2 minutes, or use the linked Google Sheet response tab with a push trigger via Google Sheets API (spreadsheets.values.get on the response sheet). Preferred: link the form to a Sheet and use the Sheet as the polling source.
Required configuration
Form ID stored in credential store (not hardcoded). Linked Sheet ID stored in credential store. Form must contain the following named fields: request_type (dropdown: New Article, Update Existing, Flag as Outdated), article_title_or_url, request_description, urgency_flag (dropdown: Normal, High), submitter_email. Field order must match the column order in the linked response Sheet.
Rate limits
Google Forms API: 500 requests/100 seconds per project. Google Sheets API: 300 read requests/minute per project. At ~30 submissions/month (roughly 1 per day), no throttling is required. If volume exceeds 200 submissions/day, implement exponential backoff on polling.
Constraints
Form edits that add, remove, or reorder questions will break field mapping. Structural form changes must be coordinated with the FullSpec team before deployment. The form must not be set to collect sign-in information unless the submitter_email field is removed and replaced with a manual email entry question.
// Input (raw form response from polling)
response_id: string
submitted_at: ISO8601 timestamp
request_type: 'New Article' | 'Update Existing' | 'Flag as Outdated'
article_title_or_url: string
request_description: string
urgency_flag: 'Normal' | 'High'
submitter_email: string

// Output (passed to Knowledge Triage Agent)
form_response_id: string
parsed_request: { type, title_or_url, description, urgency, submitter_email }
received_at: ISO8601 timestamp
Notion

Serves as the single source of truth for all article tasks, statuses, metadata, and the published knowledge base. Both agents read from and write to Notion. The integration relies on a single Notion internal integration token with access scoped to the relevant workspace pages.

Auth method
Notion Internal Integration Token (Bearer token). Create the integration at notion.so/my-integrations and share it with the Articles database and the Knowledge Base parent page. Token stored in credential store.
Required scopes
read_content | update_content | insert_content | read_user_email_addresses (for owner lookup). These are granted at integration creation time within the Notion UI, not as discrete OAuth scope strings.
Webhook / trigger setup
Notion does not provide native outbound webhooks. The orchestration layer must poll the Articles database using databases/{database_id}/query filtered by last_edited_time greater than the previous poll timestamp. Poll interval: 2 minutes. Filter on Status property changes: 'Ready for Review', 'Approved', 'Review Due'. Store the last_poll_timestamp in the workflow state between runs.
Required configuration
NOTION_ARTICLES_DB_ID stored in credential store. NOTION_KB_PARENT_PAGE_ID stored in credential store. Articles database must contain the following properties: Title (title), Status (select: Draft, Ready for Review, In Review, Approved, Published, Archived), Owner (person or email), Reviewer (person or email), Request Type (select: New, Update, Flag), Priority (select: Normal, High), Due Date (date), Review Interval Days (number), Next Review Date (date), Submitter Email (email), Google Doc URL (url), Published Date (date). Property names must match exactly as listed; changes require a corresponding update to all field mappings.
Rate limits
Notion API: 3 requests/second average; burst up to 10 requests/second. At ~30 tasks/month across both agents, no throttling is needed. For bulk operations (initial library import or tagging cleanup), implement a 400ms delay between write requests to stay within limits.
Constraints
Free Notion plans do not support API access. The workspace must be on the Plus plan or above. Integration token must be reshared manually if the parent page is moved or the integration is revoked. Do not use the public Notion OAuth flow for this integration; the internal integration token is sufficient and simpler to manage at this volume.
// Input (from triage agent, for task creation)
title: string
status: 'Draft'
owner_email: string
reviewer_email: string
request_type: 'New' | 'Update' | 'Flag'
priority: 'Normal' | 'High'
due_date: ISO8601 date
review_interval_days: integer
submitter_email: string
google_doc_url: string (if draft exists)

// Output (polled status change, to Review and Publish Coordinator Agent)
page_id: string
title: string
status: 'Ready for Review' | 'Approved' | 'Review Due'
owner_email: string
reviewer_email: string
next_review_date: ISO8601 date
google_doc_url: string
published_date: ISO8601 date (on publish)
Google Docs

Used for article drafting and inline reviewer feedback. The triage agent reads document metadata (title, last modified, sharing status) to support duplicate detection. The review coordinator retrieves the shareable link to include in Slack notifications.

Auth method
OAuth 2.0 via the same Google Workspace credential used for Google Forms. No separate connection is needed if the service account has Drive access.
Required scopes
https://www.googleapis.com/auth/drive.readonly | https://www.googleapis.com/auth/documents.readonly
Webhook / trigger setup
No webhook from Google Docs is required. The orchestration layer retrieves the document link from the Notion Articles database record (Google Doc URL property) and passes it directly into Slack message payloads. No polling of Google Docs is performed independently.
Required configuration
GOOGLE_SERVICE_ACCOUNT_EMAIL stored in credential store. GOOGLE_DRIVE_ROOT_FOLDER_ID (the shared drafts folder) stored in credential store. Drafts must be created inside this shared folder so the service account can access them. Document sharing must be set to 'Anyone with the link can comment' at minimum before the reviewer notification is sent.
Rate limits
Google Docs API: 300 read requests/minute per project. At current volume, no throttling required.
Constraints
The automation does not write to Google Docs. All draft content creation and editing remains a human step. If a Google Doc URL is missing from a Notion task record, the Slack reviewer notification must include a fallback message instructing the reviewer to locate the draft manually and update the Notion record.
// Input (from Notion task record)
google_doc_url: string
page_id: string (Notion reference)

// Output (to Slack notification payload)
doc_title: string
doc_shareable_link: string
doc_last_modified: ISO8601 timestamp
Slack

Handles all outbound notifications: direct messages to assigned owners and reviewers, team channel announcements on publication, and scheduled review reminder messages. All messages use templated Block Kit payloads with dynamic field injection.

Auth method
OAuth 2.0 via a dedicated Slack app. The app must be installed to the workspace with bot token scopes only. Bot token (xoxb-) stored in credential store as SLACK_BOT_TOKEN.
Required scopes
chat:write | users:read | users:read.email | im:write | channels:read | groups:read (for private announcement channels)
Webhook / trigger setup
Slack is outbound only in this automation. No incoming webhooks or Slack event subscriptions are required. The orchestration layer posts to the Slack API (chat.postMessage) in response to Notion status changes. For scheduled review reminders, the orchestration layer uses a time-based scheduler (cron) to evaluate articles with next_review_date within 7 days and posts reminders at 09:00 in the workspace's configured timezone.
Required configuration
SLACK_BOT_TOKEN stored in credential store. SLACK_ANNOUNCEMENT_CHANNEL_ID stored in credential store (not hardcoded). SLACK_FALLBACK_CHANNEL_ID (for error alerts) stored in credential store. Owner and reviewer Slack user IDs must be resolved at runtime by calling users.lookupByEmail using the email address from the Notion record. Do not hardcode user IDs. Message templates stored as workflow configuration variables: TEMPLATE_OWNER_ASSIGNED, TEMPLATE_REVIEWER_NOTIFY, TEMPLATE_ARTICLE_PUBLISHED, TEMPLATE_REVIEW_REMINDER, TEMPLATE_OVERDUE_REMINDER.
Rate limits
Slack API: 1 message per second per method (Tier 3: chat.postMessage). At ~30 tasks/month plus reminder cycles, peak load is well under 1 message/second. No throttling required. If the review reminder cron fires for more than 50 articles in a single run, add a 1.1-second delay between posts.
Constraints
The bot must be invited to the announcement channel and any private channels it posts to before the workflow runs. Users must have a matching email address in Slack and Notion for the lookup to succeed. If no Slack user is found for an owner email, the message must fall back to posting in SLACK_FALLBACK_CHANNEL_ID with the unresolved email included in the alert text.
// Input (from orchestration layer)
message_type: 'owner_assigned' | 'reviewer_notify' | 'article_published' | 'review_reminder' | 'overdue_reminder'
recipient_email: string
notion_page_id: string
article_title: string
doc_link: string
due_date: ISO8601 date (where applicable)
next_review_date: ISO8601 date (where applicable)

// Output (Slack API response)
ok: boolean
ts: string (message timestamp, stored for audit log)
channel: string
Loom

Used by subject-matter experts to embed screen recordings in how-to articles. The automation performs read-only link metadata retrieval at intake time if a Loom URL is included in the form submission, so the triage agent can confirm the link is accessible before writing it to the Notion task record.

Auth method
API key (Bearer token). Generate from the Loom account settings under Developer API. Token stored in credential store as LOOM_API_KEY.
Required scopes
No granular OAuth scopes; the Loom API key grants read access to videos owned by or shared with the authenticated account. The integration only calls GET /v1/videos/{video_id} to retrieve title and share status.
Webhook / trigger setup
No webhook. The orchestration layer calls the Loom API only when a Loom URL is present in the form submission. The video ID is extracted from the URL using a regex pattern matching (?:loom\.com/share/)([a-zA-Z0-9]+) before the API call is made.
Required configuration
LOOM_API_KEY stored in credential store. The regex extraction pattern stored as a workflow configuration variable: LOOM_URL_REGEX. If the Loom link is private or the token does not have access, the triage agent must flag the task in Notion with a note: 'Loom link inaccessible, manual check required' rather than failing the workflow.
Rate limits
Loom API: 50 requests/minute on the Starter plan. At current intake volume (approximately 1 submission/day), this is not a concern.
Constraints
Loom is an optional enrichment step. If no Loom URL is in the form submission, this API call is skipped entirely. The workflow must not block on Loom availability; treat any Loom API failure as a non-fatal warning.
// Input (conditional, from form response parse)
loom_url: string (optional, present only if submitter included one)
extracted_video_id: string

// Output (to Notion task record, if successful)
loom_title: string
loom_share_status: 'public' | 'workspace' | 'private'
loom_embed_url: string
Integration and API SpecPage 2 of 4
FS-DOC-05Technical

03Field mappings between tools

The tables below define the exact field mappings for each agent handoff in the workflow. Field names are in monospace format and must match the source and destination tool configurations exactly. Any rename of a property in Notion or a question label in Google Forms requires a corresponding update to the mapping.

Handoff 1: Google Forms response to Knowledge Triage Agent (Agent 1 input)

Source tool
Source field
Destination tool
Destination field
Google Forms / Sheet
`Timestamp`
Orchestration layer
`received_at` (ISO8601 converted)
Google Forms / Sheet
`What type of request is this?`
Triage Agent
`request_type`
Google Forms / Sheet
`Article title or URL (if updating)`
Triage Agent
`article_title_or_url`
Google Forms / Sheet
`Describe your request`
Triage Agent
`request_description`
Google Forms / Sheet
`How urgent is this?`
Triage Agent
`urgency_flag`
Google Forms / Sheet
`Your email address`
Triage Agent
`submitter_email`
Google Forms / Sheet
`Loom recording link (optional)`
Triage Agent
`loom_url` (optional)

Handoff 2: Knowledge Triage Agent (Agent 1) output to Notion Articles database

Source tool
Source field
Destination tool
Destination field
Triage Agent
`classified_title`
Notion Articles DB
`Title`
Triage Agent
`request_type`
Notion Articles DB
`Request Type`
Triage Agent
`priority`
Notion Articles DB
`Priority`
Triage Agent
`assigned_owner_email`
Notion Articles DB
`Owner`
Triage Agent
`assigned_reviewer_email`
Notion Articles DB
`Reviewer`
Triage Agent
`due_date`
Notion Articles DB
`Due Date`
Triage Agent
`review_interval_days`
Notion Articles DB
`Review Interval Days`
Triage Agent
`submitter_email`
Notion Articles DB
`Submitter Email`
Triage Agent
`loom_embed_url` (if present)
Notion Articles DB
`Loom URL`
Triage Agent
`duplicate_flag`
Notion Articles DB
`Status` (set to 'Duplicate Review' if true)
Triage Agent
`static: 'Draft'`
Notion Articles DB
`Status` (default on creation)

Handoff 3: Notion Articles database status change to Review and Publish Coordinator Agent (Agent 2 input)

Source tool
Source field
Destination tool
Destination field
Notion Articles DB
`id` (page ID)
Agent 2
`notion_page_id`
Notion Articles DB
`Title`
Agent 2
`article_title`
Notion Articles DB
`Status`
Agent 2
`trigger_status` ('Ready for Review' | 'Approved' | 'Review Due')
Notion Articles DB
`Owner`
Agent 2
`owner_email`
Notion Articles DB
`Reviewer`
Agent 2
`reviewer_email`
Notion Articles DB
`Google Doc URL`
Agent 2
`doc_link`
Notion Articles DB
`Due Date`
Agent 2
`due_date`
Notion Articles DB
`Next Review Date`
Agent 2
`next_review_date`
Notion Articles DB
`Review Interval Days`
Agent 2
`review_interval_days`

Handoff 4: Review and Publish Coordinator Agent (Agent 2) writes back to Notion on approval and publication

Source tool
Source field
Destination tool
Destination field
Agent 2
`static: 'Published'`
Notion Articles DB
`Status`
Agent 2
`published_date` (today)
Notion Articles DB
`Published Date`
Agent 2
`next_review_date` (published_date + review_interval_days)
Notion Articles DB
`Next Review Date`
Agent 2
`kb_section_id` (from owner category lookup)
Notion Articles DB
`KB Section` (relation property)

Handoff 5: Review and Publish Coordinator Agent (Agent 2) to Slack outbound messages

Source tool
Source field
Destination tool
Destination field
Agent 2
`owner_email`
Slack API
`user_id` (resolved via users.lookupByEmail)
Agent 2
`reviewer_email`
Slack API
`user_id` (resolved via users.lookupByEmail)
Agent 2
`article_title`
Slack Block Kit
`text` field in header block
Agent 2
`doc_link`
Slack Block Kit
`url` field in button element
Agent 2
`due_date`
Slack Block Kit
`text` field in context block
Agent 2
`next_review_date`
Slack Block Kit
`text` field in review reminder context block
Agent 2
`SLACK_ANNOUNCEMENT_CHANNEL_ID`
Slack API
`channel` parameter in chat.postMessage
Integration and API SpecPage 3 of 4
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
Two discrete workflows, one per agent. Workflow 1: Knowledge Triage Agent. Workflow 2: Review and Publish Coordinator Agent. Both workflows share a single credential store. No inter-workflow API calls are made; data is passed via the Notion Articles database as the shared state layer. A third lightweight workflow handles the scheduled review reminder cron job independently of agent triggers.
Agent 1 trigger mechanism
Poll-based. The orchestration layer polls the Google Forms linked response Sheet every 2 minutes using the Sheets API. On each poll, new rows are identified by comparing the Timestamp column against the last_processed_timestamp stored in workflow state. Only rows with a Timestamp greater than last_processed_timestamp are processed. After processing, last_processed_timestamp is updated.
Agent 2 trigger mechanism
Poll-based. The orchestration layer polls the Notion Articles database every 2 minutes using databases/{database_id}/query with a filter: last_edited_time greater than last_poll_timestamp AND Status in ['Ready for Review', 'Approved', 'Review Due']. Notion does not emit webhooks natively. Each matching page ID is checked against a processed_page_ids set stored in workflow state to prevent duplicate processing of the same status change. Webhook signature validation is not applicable here given the poll architecture.
Review reminder trigger mechanism
Time-based (cron). The scheduled reminder workflow runs daily at 09:00 workspace timezone. It queries the Notion Articles database for all records where Status equals 'Published' and Next Review Date is less than or equal to today plus 7 days. For each matching record, a Slack reminder is posted to the article owner. If Next Review Date has already passed, the overdue reminder template is used instead of the standard reminder template.
Shared credential store
All secrets and configuration IDs are stored in the automation platform's built-in encrypted credential store. No secret values are written into workflow node configurations, environment files, or code blocks directly. See the code block below for the full list of credential store entries.
Credential store: all entries must be populated in sandbox before production. Rotate tokens on a 90-day cycle.
// Credential store entries (all required before build proceeds)

// Google Workspace
GOOGLE_OAUTH_CLIENT_ID          = '<from Google Cloud Console>'
GOOGLE_OAUTH_CLIENT_SECRET      = '<from Google Cloud Console>'
GOOGLE_OAUTH_REFRESH_TOKEN      = '<generated via OAuth consent flow>'
GOOGLE_SERVICE_ACCOUNT_EMAIL    = '<service account email>'
GOOGLE_FORMS_FORM_ID            = '<target form ID from Forms URL>'
GOOGLE_FORMS_SHEET_ID           = '<linked response Sheet ID from Drive URL>'
GOOGLE_DRIVE_ROOT_FOLDER_ID     = '<shared drafts folder ID>'

// Notion
NOTION_INTEGRATION_TOKEN        = '<Internal Integration Token from notion.so/my-integrations>'
NOTION_ARTICLES_DB_ID           = '<Articles database ID from Notion URL>'
NOTION_KB_PARENT_PAGE_ID        = '<Knowledge Base parent page ID>'

// Slack
SLACK_BOT_TOKEN                 = '<xoxb- bot token from Slack app settings>'
SLACK_ANNOUNCEMENT_CHANNEL_ID   = '<#kb-updates channel ID>'
SLACK_FALLBACK_CHANNEL_ID       = '<#ops-alerts channel ID>'

// Loom
LOOM_API_KEY                    = '<API key from Loom Developer settings>'

// Workflow state variables (managed by orchestration layer, not secrets)
WORKFLOW_1_LAST_PROCESSED_TS    = '<ISO8601, updated each poll cycle>'
WORKFLOW_2_LAST_POLL_TS         = '<ISO8601, updated each poll cycle>'
WORKFLOW_2_PROCESSED_PAGE_IDS   = '<comma-separated list, cleared on each 24h cycle>'

// Template references (stored as workflow config, not credential store)
TEMPLATE_OWNER_ASSIGNED         = 'slack_block_owner_assigned_v1'
TEMPLATE_REVIEWER_NOTIFY        = 'slack_block_reviewer_notify_v1'
TEMPLATE_ARTICLE_PUBLISHED      = 'slack_block_article_published_v1'
TEMPLATE_REVIEW_REMINDER        = 'slack_block_review_reminder_v1'
TEMPLATE_OVERDUE_REMINDER       = 'slack_block_overdue_reminder_v1'
LOOM_URL_REGEX                  = '(?:loom\.com/share/)([a-zA-Z0-9]+)'

05Error handling and retry logic

Every integration point has a defined failure behaviour. Unhandled exceptions must never fail silently. Where a retry limit is reached, the workflow must post an alert to SLACK_FALLBACK_CHANNEL_ID with the workflow name, the failing node, the error code, and the affected record ID before halting.

Integration
Scenario
Required behaviour
Google Forms / Sheets poll
Sheets API returns 429 (rate limit exceeded)
Retry with exponential backoff: 30s, 60s, 120s (max 3 attempts). If all retries fail, skip this poll cycle and resume at the next scheduled interval. Post alert to SLACK_FALLBACK_CHANNEL_ID after third failure.
Google Forms / Sheets poll
Response row is missing required fields (e.g. request_type is blank)
Skip the row. Write the row index and missing fields to the workflow error log. Post alert to SLACK_FALLBACK_CHANNEL_ID with submitter_email if available. Do not advance last_processed_timestamp past this row until it is resolved.
Notion (task creation, Agent 1)
Notion API returns 503 or 500
Retry with exponential backoff: 20s, 40s, 80s (max 3 attempts). If all retries fail, hold the parsed form response in the workflow queue and alert via SLACK_FALLBACK_CHANNEL_ID. Do not re-trigger from Forms until the Notion write succeeds.
Notion (task creation, Agent 1)
Duplicate article detected by triage agent
Create the Notion task with Status set to 'Duplicate Review' rather than 'Draft'. Do not assign an owner or send a Slack notification. Post a summary to SLACK_FALLBACK_CHANNEL_ID for the operations manager to review manually.
Notion (status poll, Agent 2)
Status change is detected but page_id is already in WORKFLOW_2_PROCESSED_PAGE_IDS
Skip the page silently. This is expected behaviour when a status change is detected across multiple consecutive poll cycles before the state cache is cleared. No alert required.
Notion (publish write, Agent 2)
Write to 'Published Date' or 'Next Review Date' fails
Retry twice with a 15s delay. If the write fails after two retries, mark the task Status as 'Publish Error' in Notion (separate select option) and post an alert to SLACK_FALLBACK_CHANNEL_ID. The article is not announced in Slack until this is resolved.
Slack (owner assignment DM)
users.lookupByEmail returns no match for owner_email
Fall back to posting the owner assignment message in SLACK_FALLBACK_CHANNEL_ID, including the unresolved email address and the Notion task link. Do not block the workflow. Log the lookup failure in the error log.
Slack (chat.postMessage)
API returns 429 (rate limit)
Retry after 1.1 seconds (respecting Tier 3 limit). If sending multiple messages in a batch (review reminder cron), space each subsequent message by 1.1 seconds automatically. If a single message fails after 3 retries, log the failure and post a single consolidated alert to SLACK_FALLBACK_CHANNEL_ID.
Slack (announcement channel post)
Bot is not a member of SLACK_ANNOUNCEMENT_CHANNEL_ID
Catch the channel_not_found or not_in_channel error. Post the announcement to SLACK_FALLBACK_CHANNEL_ID instead. Halt the announcement step and alert the operations manager to add the bot to the correct channel before the next run.
Loom API (link validation)
API returns 404 or 401 for video_id
Treat as non-fatal. Write 'Loom link inaccessible' to the Notion task Notes field. Do not block task creation. Log the video_id and the error code. No Slack alert for this failure unless the same video_id fails on three separate intake runs.
Loom API (link validation)
Loom API is unreachable (timeout or 5xx)
Skip the Loom validation step for this intake run. Proceed with task creation without Loom metadata. Write 'Loom validation skipped: API unavailable' to the Notion task Notes field. No retry; the next form submission will attempt validation fresh.
Review reminder cron (Agent 2 scheduler)
Notion query for overdue articles returns zero results unexpectedly (e.g. database filter fails)
Post an alert to SLACK_FALLBACK_CHANNEL_ID: 'Review reminder cron returned zero results. Verify Notion filter and database ID.' Do not send any reminders. Log the raw query response for the FullSpec team to inspect.
All alerts sent to SLACK_FALLBACK_CHANNEL_ID must include: the workflow name, the failing node or step label, the error code or message received, the affected record ID or email where available, and a timestamp. This ensures the FullSpec team and the operations manager can triage failures without needing to access the orchestration platform logs directly. Contact support@gofullspec.com if a failure pattern recurs across more than three consecutive workflow runs.
Integration and API SpecPage 4 of 4

More documents for this process

Every document generated for Internal Knowledge Base Management.

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