Back to Team Performance Dashboard

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

Team Performance Dashboard

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

This document is the authoritative technical reference for every integration point in the Team Performance Dashboard automation. It covers authentication requirements, exact OAuth scopes, webhook and polling configuration, field-level mappings between tools, the credential store schema, and the full error-handling matrix. The FullSpec team uses this spec during build and QA; it also serves as the ongoing maintenance reference for whoever manages the automation after go-live. Nothing in this document should be implemented against production credentials until sandbox validation is complete.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agent(s)
Orchestration layer
Workflow host; schedules triggers, routes data, calls all external APIs
Internal (platform credentials)
Platform dependent
All
HubSpot
Source of sales pipeline and deal metrics
OAuth 2.0 (private app token)
Free tier sufficient for API read
Agent 1 (Data Collection)
Jira
Source of sprint velocity, open issues, and cycle time
OAuth 2.0 (3-legged) or API token + Basic Auth
Free tier sufficient for API read
Agent 1 (Data Collection)
Google Sheets
Staging area for all collected metrics; input surface for manual team-lead submissions
OAuth 2.0 (service account or user OAuth)
Google Workspace or personal account
Agent 1 (Data Collection), Agent 2 (Validation and Commentary)
Google Looker Studio
Live visual dashboard; refreshed automatically after data write
Google OAuth 2.0 (service account)
Free (linked to Google account)
Agent 2 (Validation and Commentary)
Notion
Weekly commentary storage and manager approval surface
Notion integration token (internal)
Free tier sufficient
Agent 2 (Validation and Commentary)
Slack
Submission reminders to team leads; final report distribution to management channel
Slack OAuth 2.0 (bot token)
Free tier sufficient for bot messages
Agent 1 (Data Collection), Agent 2 (Validation and Commentary)
Before you connect anything: create a dedicated sandbox or test workspace for every tool listed above and validate all credentials, scopes, and data reads against dummy data before any production credentials are stored in the credential store. HubSpot sandbox accounts, a Jira test project, a duplicate Google Sheet, a test Notion page, and a private Slack channel are the minimum sandbox surfaces required.
Integration and API SpecPage 1 of 4
FS-DOC-05Technical

02Per-tool integration detail

HubSpot

Used by the Data Collection Agent to retrieve deal pipeline metrics on the Monday 7:00 AM schedule. All calls are read-only. A HubSpot private app token is the recommended auth method because it does not expire on short rotations and does not require a full OAuth consent screen per user.

Auth method
Private app token (Bearer token in Authorization header). Alternatively, OAuth 2.0 authorization code flow with offline access. Private app token is preferred for server-to-server automation.
Required scopes
crm.objects.deals.read, crm.objects.contacts.read, crm.objects.pipelines.read, crm.schemas.deals.read
Webhook / trigger setup
No inbound webhook required. The agent polls HubSpot on a fixed Monday 7:00 AM schedule using a cron trigger in the orchestration layer. No HubSpot webhook subscription is needed for this integration.
Required configuration
HUBSPOT_PRIVATE_APP_TOKEN stored in credential store (never hardcoded). HUBSPOT_PIPELINE_ID stored in credential store (the specific pipeline to query). HUBSPOT_DEAL_STAGE_IDS stored as a comma-separated list in credential store for stage-level filtering. Base URL: https://api.hubapi.com
Key endpoints
GET /crm/v3/objects/deals (paginated, filter by pipeline and close date range). GET /crm/v3/pipelines/deals/{pipelineId}/stages. GET /crm/v3/objects/deals/{dealId} for per-deal detail if needed.
Rate limits
Free and Starter: 100 requests per 10 seconds, 250,000 requests per day. At current volume (one weekly run, approximately 5 to 10 API calls per run), throttling is NOT required. Build in a 200 ms inter-request delay as a precaution.
Constraints
Pagination required: default page size is 100 objects, use the paging.next.after cursor for subsequent pages. Fields not exposed via API (UI-only computed fields) must be identified during discovery and replaced with API-available equivalents.
// Input
HUBSPOT_PIPELINE_ID, HUBSPOT_DEAL_STAGE_IDS, date_range { start: Monday 00:00 UTC, end: Sunday 23:59 UTC }
// Output
deals_count: integer
pipeline_value_usd: float
deals_by_stage: { stage_id: string, count: integer, value: float }[]
weighted_forecast_usd: float
Jira

Used by the Data Collection Agent to retrieve sprint velocity, open issue counts, and cycle time for the current reporting period. Jira Cloud REST API v3 is assumed. Authentication uses an API token paired with the admin service account email via HTTP Basic Auth (base64-encoded).

Auth method
HTTP Basic Auth: Base64(service_account_email:JIRA_API_TOKEN) in Authorization header. OAuth 2.0 (3-legged, scopes below) is the alternative if the organisation enforces SSO.
Required scopes
read:jira-work, read:jira-user (for OAuth 2.0 flow). For API token Basic Auth, scopes are implicit to the service account's project permissions; grant read-only access to the target project only.
Webhook / trigger setup
No inbound webhook required. Agent polls Jira on the same Monday 7:00 AM schedule. Sprint data is queried by board ID and sprint state.
Required configuration
JIRA_BASE_URL stored in credential store (e.g. https://yourcompany.atlassian.net). JIRA_API_TOKEN stored in credential store. JIRA_SERVICE_ACCOUNT_EMAIL stored in credential store. JIRA_BOARD_ID stored in credential store. JIRA_PROJECT_KEY stored in credential store.
Key endpoints
GET /rest/agile/1.0/board/{boardId}/sprint?state=active (active sprint). GET /rest/agile/1.0/sprint/{sprintId}/issue?fields=status,resolutiondate,created (issues for cycle time). GET /rest/api/3/search?jql=project={KEY}+AND+status!=Done (open issue count).
Rate limits
Jira Cloud enforces rate limiting at approximately 10 requests per second per API token. At current volume (one weekly run, approximately 6 to 8 calls), throttling is NOT required. Add 300 ms inter-request delay to remain well within limits.
Constraints
Cycle time must be computed client-side from issue created and resolutiondate fields; Jira does not expose a native cycle time field via the standard REST API. Sprint velocity requires summing story points from completed issues in the previous sprint, not the active one.
// Input
JIRA_BOARD_ID, JIRA_PROJECT_KEY, active_sprint_id (resolved from board endpoint)
// Output
sprint_velocity_points: integer
open_issue_count: integer
avg_cycle_time_days: float
sprint_name: string
sprint_end_date: ISO8601 string
Google Sheets

Used by both agents. The Data Collection Agent writes API-retrieved metrics to a defined staging area; the Validation and Commentary Agent reads from the same sheet to run validation logic. Team leads also write manual metric submissions directly into designated input cells. A service account is the recommended auth method to avoid user-session expiry.

Auth method
Google OAuth 2.0 service account. Download the service account JSON key, store it in the credential store as GOOGLE_SERVICE_ACCOUNT_JSON. Share the target spreadsheet with the service account email (Editor role).
Required scopes
https://www.googleapis.com/auth/spreadsheets (read and write). https://www.googleapis.com/auth/drive.file (if creating new sheets programmatically).
Webhook / trigger setup
No inbound webhook. The agent reads and writes on its own schedule. To detect when a team lead has filled in a manual cell, the Validation and Commentary Agent polls the sheet at a defined interval (every 15 minutes after 7:00 AM) or uses a 90-minute maximum wait as defined in the process.
Required configuration
GOOGLE_SHEETS_STAGING_SPREADSHEET_ID stored in credential store. GOOGLE_SHEETS_STAGING_TAB_NAME stored in credential store (e.g. WeeklyStaging). GOOGLE_SHEETS_INPUT_RANGE stored in credential store (e.g. WeeklyStaging!A2:Z100). Column headers must match the field mapping table exactly and must not be rearranged without updating the mapping config.
Rate limits
Sheets API v4: 300 requests per minute per project, 60 requests per minute per user. At current volume (approximately 10 to 15 read/write calls per weekly run), throttling is NOT required.
Constraints
All date values must be written as ISO 8601 strings (YYYY-MM-DD) to avoid regional format ambiguity. Formulas in the staging sheet must not be overwritten by the automation; the agent must write only to explicitly mapped data cells. The sheet structure (column order and row offset) is a config dependency, not a code dependency.
// Input (write, Data Collection Agent)
week_start_date, deals_count, pipeline_value_usd, weighted_forecast_usd,
sprint_velocity_points, open_issue_count, avg_cycle_time_days,
manual_metric_[n] (populated by team leads)
// Output (read, Validation and Commentary Agent)
full_row object matching staging schema
missing_fields: string[] (fields where value is null or empty)
anomaly_flags: { field: string, current: float, previous: float, pct_change: float }[]
Google Looker Studio

The Looker Studio dashboard is connected directly to the Google Sheets staging spreadsheet as its data source. Refreshing the dashboard means triggering a data source cache invalidation via the Looker Studio API (where available) or relying on Looker Studio's automatic refresh interval. The automation ensures the Google Sheets write is complete before the refresh call is made.

Auth method
Google OAuth 2.0 service account (same credentials as Google Sheets integration). The service account must be granted Viewer or Editor access to the Looker Studio report.
Required scopes
https://www.googleapis.com/auth/datastudio (Looker Studio API access for report and data source management).
Webhook / trigger setup
No inbound webhook. The orchestration layer fires a Looker Studio cache-refresh API call after confirming the Google Sheets write step is complete. If the Looker Studio REST API is not available on the target account tier, the data source is configured with a refresh interval of 15 minutes or less so the dashboard updates automatically after the sheet write.
Required configuration
LOOKER_STUDIO_REPORT_ID stored in credential store. LOOKER_STUDIO_DATASOURCE_ID stored in credential store. Looker Studio data source must point to GOOGLE_SHEETS_STAGING_SPREADSHEET_ID with header row defined.
Rate limits
Looker Studio API: subject to Google API quotas (100 requests per 100 seconds per user). One refresh call per weekly run is well within limits. Throttling is NOT required.
Constraints
Looker Studio does not support programmatic chart or layout changes via API. All visual configuration is done manually at build time. The automation only triggers a data refresh, not a structural update. If the data source schema changes (new columns), the Looker Studio report must be manually updated to reflect new fields.
// Input
LOOKER_STUDIO_DATASOURCE_ID, trigger: google_sheets_write_confirmed = true
// Output
refresh_status: 'success' | 'pending' | 'error'
refreshed_at: ISO8601 timestamp
Notion

Used by the Validation and Commentary Agent to write the AI-drafted weekly summary to a defined Notion page and to surface the manager approval gate. The automation appends a new block to a designated Notion performance page each week. The manager reads and edits the draft in Notion, then triggers approval (via a Notion checkbox property or an external approval mechanism connected to the orchestration layer).

Auth method
Notion internal integration token. Create an internal integration in Notion workspace settings, copy the token, and share the target page and database with the integration. Store as NOTION_INTEGRATION_TOKEN in credential store.
Required scopes
Notion internal integrations use capability-based permissions set at creation time. Required capabilities: Read content, Update content, Insert content. No OAuth flow is required for internal integrations.
Webhook / trigger setup
No native Notion webhook available for approval detection. The orchestration layer polls a designated Notion page property (e.g. a checkbox titled Approved, or a select property set to Approved) every 5 minutes after the draft is written, up to a configurable maximum wait (recommended: 4 hours before escalation alert).
Required configuration
NOTION_INTEGRATION_TOKEN stored in credential store. NOTION_PERFORMANCE_PAGE_ID stored in credential store (the parent page where weekly entries are appended). NOTION_APPROVAL_PROPERTY_NAME stored as config (e.g. 'Approved'). Commentary template structure must be defined at build time: section headings, metric highlight format, and anomaly flag format must not be changed without updating the prompt config.
Rate limits
Notion API: 3 requests per second average, burst up to 10 per second. Polling every 5 minutes produces 1 request per poll. Throttling is NOT required at current volume.
Constraints
Notion block content is append-only via API; the automation cannot edit previously written blocks. Each weekly entry should be a new child page or toggled block under the parent performance page to avoid conflicts. The integration token must have access explicitly shared to every page it writes to; workspace-wide access is not granted by default.
// Input
validated_data_set: object (from Google Sheets read)
anomaly_flags: { field: string, pct_change: float }[]
ai_commentary_draft: string (generated by LLM step in orchestration layer)
// Output
notion_page_url: string
approval_status: 'pending' | 'approved' | 'edited_and_approved'
approved_commentary: string (final text after manager edits)
Slack

Used by both agents. The Data Collection Agent sends targeted submission reminders to individual team leads for missing manual metric inputs. The Validation and Commentary Agent (after manager approval) posts the final dashboard link and approved commentary to the management Slack channel. A single Slack bot app handles both use cases.

Auth method
Slack OAuth 2.0 bot token (xoxb- prefix). Create a Slack app in the target workspace, add the bot to required channels, and store the bot token as SLACK_BOT_TOKEN in credential store.
Required scopes
chat:write (post messages as the bot), chat:write.public (post to channels the bot is not a member of, if needed), users:read (resolve user IDs from email for DM reminders), users:read.email (look up user by email address), im:write (open DM channels for reminders).
Webhook / trigger setup
No inbound Slack webhook required. The automation sends outbound messages only. Incoming interactions (such as a manager clicking an Approve button in Slack) would require Slack Interactivity and a public HTTPS endpoint for the callback; this is optional and only needed if approval is handled via Slack rather than Notion.
Required configuration
SLACK_BOT_TOKEN stored in credential store. SLACK_MANAGEMENT_CHANNEL_ID stored in credential store (target channel for final report distribution). SLACK_REMINDER_CHANNEL_ID or per-user DM logic stored in credential store or config. TEAM_LEAD_SLACK_USER_IDS stored as a JSON map (email to Slack user ID) in credential store, populated during onboarding. Message templates for reminders and final distribution must be defined in the orchestration config, not hardcoded in function bodies.
Rate limits
Slack Web API: Tier 3 methods (chat.postMessage) allow approximately 50 requests per minute. At current volume (approximately 3 to 6 reminder messages plus 1 distribution message per week), throttling is NOT required.
Constraints
The bot must be invited to every channel it posts to. DMs require the users:read.email scope and a prior im.open call to obtain the channel ID before posting. Block Kit formatting is recommended for the final distribution message to include the dashboard link as a button; plain text is acceptable for reminder DMs.
// Input (reminder, Data Collection Agent)
missing_metric_fields: string[], team_lead_user_id: string, google_sheets_input_url: string
// Output (reminder)
message_ts: string (Slack message timestamp for threading if needed)
// Input (distribution, Validation and Commentary Agent)
approved_commentary: string, looker_studio_report_url: string, week_label: string
// Output (distribution)
message_ts: string, channel_id: string
Integration and API SpecPage 2 of 4
FS-DOC-05Technical

03Field mappings between tools

The tables below define every field that crosses a tool boundary during an automated run. Use exact field names as shown (monospace) when configuring the orchestration layer. Any deviation in field naming will cause silent mapping failures in the Google Sheets staging area.

Handoff 1: HubSpot to Google Sheets (Data Collection Agent)

Source tool
Source field
Destination tool
Destination field
HubSpot
properties.amount
Google Sheets
pipeline_value_usd
HubSpot
properties.dealstage
Google Sheets
deal_stage_id
HubSpot
total (count of results)
Google Sheets
deals_count
HubSpot
properties.hs_forecast_amount
Google Sheets
weighted_forecast_usd
HubSpot
properties.closedate
Google Sheets
deal_close_date

Handoff 2: Jira to Google Sheets (Data Collection Agent)

Source tool
Source field
Destination tool
Destination field
Jira
sprint.name
Google Sheets
sprint_name
Jira
sprint.endDate
Google Sheets
sprint_end_date
Jira
SUM(issues[].story_points) where status=Done
Google Sheets
sprint_velocity_points
Jira
COUNT(issues[]) where status!=Done
Google Sheets
open_issue_count
Jira
AVG(resolutiondate - created) in days
Google Sheets
avg_cycle_time_days

Handoff 3: Google Sheets to Notion (Validation and Commentary Agent)

Source tool
Source field
Destination tool
Destination field
Google Sheets
week_start_date
Notion
page.properties.Week
Google Sheets
deals_count
Notion
block.paragraph (metric highlight section)
Google Sheets
pipeline_value_usd
Notion
block.paragraph (metric highlight section)
Google Sheets
sprint_velocity_points
Notion
block.paragraph (metric highlight section)
Google Sheets
anomaly_flags (JSON array)
Notion
block.callout (flagged items section)
Google Sheets
missing_fields (JSON array)
Notion
block.callout (missing data warning section)
Google Sheets
manual_metric_[n]
Notion
block.paragraph (team lead inputs section)

Handoff 4: Notion to Slack (Validation and Commentary Agent, post-approval)

Source tool
Source field
Destination tool
Destination field
Notion
page.url
Slack
blocks[].accessory.url (button link)
Notion
approved_commentary (plain text export)
Slack
blocks[].text.text (section block)
Google Sheets
week_start_date
Slack
blocks[].text.text (message header)
Google Sheets
looker_studio_report_url (config value)
Slack
blocks[].accessory.url (dashboard button)
Integration and API SpecPage 3 of 4
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
Two discrete workflows in the automation platform: one per agent. Workflow 1 handles the Data Collection Agent (Monday 7:00 AM cron trigger, HubSpot pull, Jira pull, Slack reminders, Google Sheets write). Workflow 2 handles the Validation and Commentary Agent (triggered by Workflow 1 completion event or polling confirmation that mandatory fields are populated, with a 90-minute maximum wait). Both workflows share a single credential store. No credentials are passed between workflows via message payloads.
Agent 1 trigger mechanism
Fixed cron schedule: Monday 07:00 AM (timezone configured per the team's local timezone, stored as SCHEDULE_TIMEZONE in config). Poll-based. No inbound webhook. The trigger fires unconditionally; downstream logic handles partial data gracefully.
Agent 2 trigger mechanism
Event-based: Workflow 1 emits a completion signal (an internal platform event or a flag written to a designated Google Sheets status cell, e.g. collection_status = complete). Workflow 2 listens for this event or polls the status cell every 15 minutes. If the 90-minute wait elapses without all mandatory fields being populated, Workflow 2 proceeds with available data and flags missing fields in the Notion draft. A second poll loop (every 5 minutes, up to 4 hours) checks the Notion approval property before firing the Slack distribution step.
Slack signature validation
If Slack Interactivity is enabled for the approval button flow, all inbound POST requests from Slack must be validated using the SLACK_SIGNING_SECRET and the X-Slack-Signature header (HMAC-SHA256). Requests failing validation must return HTTP 403 and must not trigger any workflow action. SLACK_SIGNING_SECRET is stored in the credential store.
LLM step
The AI commentary draft is generated within the orchestration layer using a prompt template stored in config (not hardcoded). The prompt includes the validated metric data, anomaly flags, and a tone/format instruction. The LLM API key is stored as LLM_API_KEY in the credential store. Model selection and temperature settings are stored in config as LLM_MODEL and LLM_TEMPERATURE.
Shared credential store
All secrets are stored in the automation platform's native encrypted credential store. No secret appears in workflow node configuration fields in plaintext. Variable names used across both workflows are listed in the code block below.
Credential store contents (all values encrypted at rest; never hardcoded in workflow nodes)
// HubSpot
HUBSPOT_PRIVATE_APP_TOKEN        = 'pat-na1-xxxxxxxxxxxxxxxxxxxx'
HUBSPOT_PIPELINE_ID              = 'xxxxxxxxxxxxxxxxxxxxxxxx'
HUBSPOT_DEAL_STAGE_IDS           = 'stageid1,stageid2,stageid3'

// Jira
JIRA_BASE_URL                    = 'https://yourcompany.atlassian.net'
JIRA_API_TOKEN                   = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx'
JIRA_SERVICE_ACCOUNT_EMAIL       = 'automation@yourcompany.com'
JIRA_BOARD_ID                    = '42'
JIRA_PROJECT_KEY                 = 'ENG'

// Google (shared service account)
GOOGLE_SERVICE_ACCOUNT_JSON      = '{ "type": "service_account", ... }'
GOOGLE_SHEETS_STAGING_SPREADSHEET_ID = '1BxiMVs0XRA5nFMdKvBdBZjgmUUqptlbs74OgVE2upms'
GOOGLE_SHEETS_STAGING_TAB_NAME   = 'WeeklyStaging'
GOOGLE_SHEETS_INPUT_RANGE        = 'WeeklyStaging!A2:Z200'

// Looker Studio
LOOKER_STUDIO_REPORT_ID          = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
LOOKER_STUDIO_DATASOURCE_ID      = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
LOOKER_STUDIO_REPORT_URL         = 'https://lookerstudio.google.com/reporting/...'

// Notion
NOTION_INTEGRATION_TOKEN         = 'secret_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
NOTION_PERFORMANCE_PAGE_ID       = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
NOTION_APPROVAL_PROPERTY_NAME    = 'Approved'

// Slack
SLACK_BOT_TOKEN                  = 'xoxb-xxxxxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx'
SLACK_SIGNING_SECRET             = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
SLACK_MANAGEMENT_CHANNEL_ID      = 'C0XXXXXXXXX'
SLACK_REMINDER_CHANNEL_ID        = 'C0XXXXXXXXX'
TEAM_LEAD_SLACK_USER_IDS         = '{ "lead1@co.com": "U0XXXXXXXXX", "lead2@co.com": "U0XXXXXXXXX" }'

// LLM
LLM_API_KEY                      = 'sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxx'
LLM_MODEL                        = 'gpt-4o'
LLM_TEMPERATURE                  = '0.3'

// Schedule
SCHEDULE_TIMEZONE                = 'America/New_York'
ANOMALY_THRESHOLD_PCT            = '25'
APPROVAL_POLL_INTERVAL_MINUTES   = '5'
APPROVAL_MAX_WAIT_MINUTES        = '240'
COLLECTION_MAX_WAIT_MINUTES      = '90'

05Error handling and retry logic

Unhandled exceptions must never fail silently. Every integration point must write a structured error log entry and trigger an alert (Slack DM to the process owner or email to support@gofullspec.com) before the workflow exits. A failed run that produces no output and no notification is a critical defect.
Integration
Scenario
Required behaviour
HubSpot API
HTTP 401 Unauthorized (token expired or revoked)
Halt workflow immediately. Log error with timestamp and token reference (not the token value). Send Slack DM alert to process owner. Do NOT retry with the same token. Await manual credential rotation.
HubSpot API
HTTP 429 Too Many Requests
Retry after the duration specified in the Retry-After response header. If no header present, apply exponential backoff: 10 s, 30 s, 90 s. After 3 failed retries, log error and alert process owner via Slack.
HubSpot API
HTTP 5xx server error
Retry with exponential backoff: 30 s, 60 s, 120 s (3 attempts). If all retries fail, write partial data collected so far to Google Sheets with a status flag of 'hubspot_error'. Continue to Jira step. Alert process owner.
Jira API
HTTP 401 or 403 (auth failure or permission denied)
Halt Jira step immediately. Write 'jira_auth_error' to the Google Sheets status cell. Log error. Send Slack DM alert to process owner and Engineering Lead. Do NOT retry until credentials are confirmed.
Jira API
HTTP 5xx or connection timeout (>10 s)
Retry with exponential backoff: 30 s, 60 s, 120 s (3 attempts). If all retries fail, write 'jira_unavailable' to Google Sheets status cell and proceed with remaining data. Alert process owner via Slack.
Google Sheets
Write operation fails (API error or quota exceeded)
Retry twice with a 15 s delay between attempts. If both retries fail, halt workflow, log the full payload that failed to write to the platform error log, and send an alert to the process owner. Manual fallback: process owner writes data manually for the affected week.
Google Sheets
Manual metric fields not populated after 90-minute wait
Proceed with available data. Write 'missing: [field_name]' to the relevant cells. Flag missing fields in the Notion commentary draft. Send a second Slack reminder to the relevant team lead(s). Do not block the rest of the workflow.
Looker Studio
Refresh API call returns error or datasource ID not found
Log the error and notify the process owner via Slack. The Google Sheets data is already written and correct; the dashboard will auto-refresh within 15 minutes via its configured interval. No retry loop required. Annotate the Notion commentary with a note that manual dashboard refresh may be needed.
Notion
Page write fails (integration token invalid or page ID not found)
Retry once after 30 s. If retry fails, log error and send Slack alert. Manual fallback: process owner is notified with the validated data payload in the Slack alert message so commentary can be drafted manually. Do not proceed to the approval poll loop if the page write failed.
Notion
Approval property not set after 4-hour maximum wait
Send an escalation Slack DM to the process owner and the Founder (as defined in TEAM_LEAD_SLACK_USER_IDS config). Log a timeout event. Do not distribute the report. Halt the workflow and await manual intervention. Do not re-trigger automatically.
Slack
chat.postMessage returns error (invalid token, channel not found, or rate limit)
For rate limit (HTTP 429): retry after the Retry-After header value, up to 3 times. For invalid token or channel not found: log error immediately, halt the affected step, and send an email alert to support@gofullspec.com. Manual fallback: process owner distributes the Looker Studio link and Notion commentary URL directly.
LLM (commentary generation)
API call fails, times out, or returns empty response
Retry once after 20 s. If retry fails, write a structured fallback template to Notion in place of the AI draft (pre-defined skeleton with metric values inserted and a note reading 'AI commentary unavailable this week'). Alert process owner via Slack. Do not block the approval gate.
Integration and API SpecPage 4 of 4

More documents for this process

Every document generated for Team Performance Dashboard.

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