Back to New Tool Evaluation & Rollout

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

New Tool Evaluation and Rollout

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

This document defines every API connection, authentication requirement, field mapping, and error behaviour for the New Tool Evaluation and Rollout automation. It is written for the FullSpec build team and covers the five named integration tools plus the orchestration layer. Use this specification as the canonical reference during build, credential setup, and QA. Where a setting is not yet confirmed (such as a specific DocuSign template ID or Notion database ID), the relevant environment variable name is shown and the value must be recorded in the credential store before the workflow is activated.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agent(s)
Jira
Ticket creation, status tracking, rejection recording
OAuth 2.0 (3-legged) / API token
Free (cloud)
Agent 1, Agent 3
Notion
Software register queries, scorecard and checklist creation, register updates
OAuth 2.0 (internal integration token)
Free
Agent 1, Agent 2, Agent 3
Google Workspace
Intake form trigger, approval email dispatch, follow-up reminders
OAuth 2.0 (service account)
Business Starter
Agent 2
DocuSign
Vendor agreement envelope creation and signature flow
OAuth 2.0 (JWT grant)
Standard ($25/mo)
Agent 3
Slack
Requestor acknowledgement, rollout notification
OAuth 2.0 (bot token)
Free
Agent 1, Agent 3
Workflow automation platform
Orchestration layer: hosts all three agent workflows, manages credential store, executes polling and webhook listeners
Platform-native credential store
Paid tier (webhooks required)
All agents
Before you connect anything: configure every integration against its sandbox or developer environment first. Use Jira sandbox projects, the Notion API in a test workspace, the DocuSign sandbox (demo.docusign.net), and a Slack test workspace. Do not store production credentials in the platform until end-to-end sandbox testing has passed all test cases in the QA Plan.

02Per-tool integration detail

Jira

Used by Agent 1 (Request Intake Agent) to create and label evaluation tickets, and by Agent 3 (Procurement and Rollout Agent) to record approval outcomes and rejections. The integration targets the Jira Cloud REST API v3.

Auth method
OAuth 2.0 (3-legged) with a dedicated service account. Alternatively, an API token scoped to the build service account email may be used for server-to-server calls. Store as JIRA_API_TOKEN and JIRA_SERVICE_EMAIL in the credential store.
Required scopes
read:jira-work, write:jira-work, manage:jira-project (required to set custom field values on ticket create). If using OAuth 2.0 (3LO): read:me, read:jira-user.
Webhook / trigger setup
Agent 2 polls the Jira REST API endpoint GET /rest/api/3/issue/{issueKey} or uses a Jira automation webhook (Jira Cloud native) to fire when a ticket transitions to status 'Evaluation In Progress'. Configure the webhook in Jira: Project Settings > Automation > New rule > Issue transitioned. Deliver to the orchestration layer's inbound webhook URL. Validate the shared secret header X-Atlassian-Token against JIRA_WEBHOOK_SECRET.
Required configuration
PROJECT_KEY: the Jira project key for IT evaluations (e.g. ITEVAL). JIRA_EVALUATION_BOARD_ID: numeric board ID for status queries. Custom fields: cf[tool_name], cf[requestor_email], cf[use_case], cf[user_count], cf[budget_range], cf[duplicate_flag]. All IDs stored in the credential store, never hardcoded. Status names must match exactly: 'Intake', 'Evaluation In Progress', 'Approved', 'Rejected'.
Rate limits
Jira Cloud: 10 requests/second per OAuth token. At ~3 to 6 evaluations/month, peak calls are well below this threshold. No throttling logic is required at current volume; implement a basic 200ms inter-request delay as a precaution.
Constraints
Custom field IDs differ between Jira instances and must be resolved via GET /rest/api/3/field at setup time. Webhook delivery is not guaranteed; implement a 5-minute poll fallback for status changes in case the webhook is missed.
// Input (Agent 1)
POST /rest/api/3/issue
{ projectKey, summary, description, customFields: { tool_name, requestor_email, use_case, user_count, budget_range, duplicate_flag } }

// Input (Agent 3 - rejection)
PUT /rest/api/3/issue/{issueKey}/transitions
{ transition: { id: REJECTED_TRANSITION_ID } }

// Output
{ id, key, self, fields: { status, cf[duplicate_flag], cf[tool_name] } }
Notion

Used by all three agents. Agent 1 queries the software register for duplicate detection. Agent 2 creates the security checklist page and evaluation scorecard page. Agent 3 appends the approved tool entry to the software register.

Auth method
Notion internal integration token. Create a dedicated integration at notion.so/my-integrations, share the three target databases with the integration, and store the token as NOTION_API_TOKEN.
Required scopes
Notion integrations use capability flags, not OAuth scopes. Required capabilities: Read content, Insert content, Update content. The integration must be shared explicitly with each database page used.
Webhook / trigger setup
Notion does not natively emit webhooks. Agent 2 polls the security checklist database using POST /v1/databases/{checklist_db_id}/query with a filter on the 'Status' property for the value 'Complete'. Poll interval: 15 minutes. NOTION_CHECKLIST_DB_ID stored in credential store.
Required configuration
NOTION_SOFTWARE_REGISTER_DB_ID: the database ID of the master software register. NOTION_CHECKLIST_TEMPLATE_PAGE_ID: the page ID of the security checklist template to duplicate per evaluation. NOTION_SCORECARD_TEMPLATE_PAGE_ID: the page ID of the scorecard template. Software register schema must include properties: Tool Name (title), Vendor (text), Monthly Cost (number), Licence Count (number), Renewal Date (date), Owner (person), Status (select: Active/Archived), Jira Ticket (url). Scorecard schema must include: Tool Name, Request Date, Requestor, Use Case, Security Score (number 1-5), Integration Fit (number 1-5), Cost Rating (number 1-5), Recommendation (select: Approve/Reject/Defer), Approved By, Approval Date.
Rate limits
Notion API: 3 requests/second average (burst to 10). At current volume (3 to 6 evaluations/month), no throttling is needed. Include a 400ms delay between sequential Notion calls within a single agent run.
Constraints
Database IDs and page IDs are UUIDs that must be extracted from the Notion URL and stored at setup. Template pages must be duplicated (POST /v1/pages) rather than edited in place to preserve the master. The duplicate-check query uses a text filter on the Tool Name property; the software register must have consistent, non-abbreviated tool names for accurate matching.
// Input (Agent 1 - duplicate check)
POST /v1/databases/{NOTION_SOFTWARE_REGISTER_DB_ID}/query
{ filter: { property: 'Tool Name', title: { contains: intake_tool_name } } }

// Input (Agent 2 - create checklist page)
POST /v1/pages
{ parent: { database_id: NOTION_CHECKLIST_DB_ID }, properties: { 'Tool Name': ..., 'Jira Ticket': ..., 'Assigned To': ... } }

// Input (Agent 3 - register update)
POST /v1/pages
{ parent: { database_id: NOTION_SOFTWARE_REGISTER_DB_ID }, properties: { 'Tool Name', 'Vendor', 'Monthly Cost', 'Licence Count', 'Renewal Date', 'Owner', 'Status': 'Active', 'Jira Ticket' } }

// Output
{ object: 'page', id: page_uuid, url: notion_page_url, properties: { ... } }
Integration and API SpecPage 1 of 3
FS-DOC-05Technical
Google Workspace (Gmail + Google Forms)

Used by Agent 2 (Evaluation and Approval Agent). Google Forms provides the structured intake trigger. Gmail sends the approval request email to the relevant manager and dispatches 48-hour reminder emails if no response is received.

Auth method
OAuth 2.0 via a Google service account with domain-wide delegation. Store the service account JSON key as GOOGLE_SERVICE_ACCOUNT_JSON. Impersonation target (the IT Manager's email address) stored as GOOGLE_IMPERSONATION_EMAIL.
Required scopes
https://www.googleapis.com/auth/gmail.send, https://www.googleapis.com/auth/gmail.readonly (for reply detection), https://www.googleapis.com/auth/forms.responses.readonly, https://www.googleapis.com/auth/drive.readonly (to read form response attachments if present).
Webhook / trigger setup
Google Forms does not natively push webhooks. Configure a Google Apps Script trigger (onFormSubmit) on the linked Google Sheet to POST the form response payload to the orchestration layer's inbound webhook URL. Alternatively, the orchestration layer polls the Forms API endpoint GET /v1/forms/{formId}/responses on a 5-minute interval. Store GOOGLE_FORM_ID in the credential store. For reply detection (approval confirmation), poll the Gmail API GET /gmail/v1/users/me/messages with a q parameter filtering by subject thread ID and label INBOX every 30 minutes.
Required configuration
GOOGLE_FORM_ID: the Forms resource ID for the intake form. APPROVAL_EMAIL_TEMPLATE_SUBJECT: standardised subject line used for reply-thread matching (e.g. '[ITEVAL] Tool Approval Request: {tool_name}'). REMINDER_DELAY_HOURS: 48 (number of hours before first reminder fires). MANAGER_EMAIL: the approving manager's email, configurable per evaluation based on budget threshold. All values stored in credential store.
Rate limits
Gmail API: 250 quota units/second per user; sending an email costs 100 units. Google Forms API: 300 requests/minute. At 3 to 6 evaluations/month generating at most 2 to 3 emails each, volume is negligible. No throttling required.
Constraints
Gmail reply detection based on subject-line matching is fragile if the manager changes the subject. Prefer reading the In-Reply-To header from Gmail API message threads (GET /gmail/v1/users/me/threads/{threadId}) for reliable chaining. The approval email must include a clear structured response mechanism (approve/reject link or keyword) to allow the automation to parse the decision without ambiguity.
// Input (form submission poll)
GET /v1/forms/{GOOGLE_FORM_ID}/responses
{ pageSize: 10, filter: 'timestamp > last_polled_at' }

// Input (send approval email)
POST /gmail/v1/users/me/messages/send
{ raw: base64_encoded_MIME_message }
  Subject: [ITEVAL] Tool Approval Request: {tool_name}
  Body: evaluation_summary_html + approve_link + reject_link

// Output
{ id: message_id, threadId, labelIds, snippet }
DocuSign

Used by Agent 3 (Procurement and Rollout Agent). Triggered when management approval is recorded in Jira. Creates and sends a DocuSign envelope from a pre-configured vendor agreement template to the required signatories. Completion status is polled to trigger the Notion register update.

Auth method
OAuth 2.0 JWT Bearer Grant (server-to-server). Store the RSA private key as DOCUSIGN_RSA_PRIVATE_KEY, the integration key (client ID) as DOCUSIGN_INTEGRATION_KEY, the impersonated user GUID as DOCUSIGN_USER_ID, and the account ID as DOCUSIGN_ACCOUNT_ID. JWT tokens expire after 1 hour; implement automatic token refresh.
Required scopes
signature, impersonation. The impersonated user must have DocuSign Administrator or Sender role within the account.
Webhook / trigger setup
Configure a DocuSign Connect webhook (Envelope Events: envelope-completed, envelope-declined, envelope-voided) to POST to the orchestration layer's inbound webhook URL. Validate the HMAC-SHA256 signature on the X-DocuSign-Signature-1 header using DOCUSIGN_CONNECT_HMAC_KEY stored in the credential store. Implement a poll fallback: GET /v2.1/accounts/{accountId}/envelopes/{envelopeId} every 15 minutes for envelopes in 'sent' status.
Required configuration
DOCUSIGN_TEMPLATE_ID: the envelope template ID for the vendor agreement (must be pre-loaded in the DocuSign account). DOCUSIGN_SIGNER_ROLE_VENDOR: role name in the template for the vendor signatory. DOCUSIGN_SIGNER_ROLE_IT: role name for the IT Manager signatory. DOCUSIGN_SIGNER_ROLE_FINANCE: role name for the Finance Controller (optional, triggered when deal value exceeds configured threshold). DOCUSIGN_ENV: 'demo' or 'production'. Template placeholders required: {{tool_name}}, {{vendor_name}}, {{monthly_cost}}, {{licence_count}}, {{it_manager_name}}, {{approval_date}}.
Rate limits
DocuSign Standard plan: 100 envelopes/month included. At 3 to 6 evaluations/month, worst case is 6 envelopes/month. No throttling required. API rate limit: 1,000 calls/hour. Not a constraint at current volume.
Constraints
The vendor agreement template must be created and configured in DocuSign before the agent is activated. Each new agreement type (e.g. SaaS subscription vs. enterprise licence) requires a separate template ID. Template IDs must not be hardcoded; store all in the credential store. If the envelope is declined, Agent 3 must update the Jira ticket to 'Rejected' and notify via Slack rather than silently failing.
// Input (create envelope from template)
POST /v2.1/accounts/{DOCUSIGN_ACCOUNT_ID}/envelopes
{
  templateId: DOCUSIGN_TEMPLATE_ID,
  status: 'sent',
  templateRoles: [
    { roleName: DOCUSIGN_SIGNER_ROLE_VENDOR, name: vendor_contact_name, email: vendor_contact_email },
    { roleName: DOCUSIGN_SIGNER_ROLE_IT, name: it_manager_name, email: it_manager_email }
  ],
  emailSubject: 'Agreement for {tool_name} - Action Required',
  customFields: { textCustomFields: [ { name: 'tool_name', value: tool_name }, ... ] }
}

// Output (Connect webhook payload)
{ envelopeId, status: 'completed'|'declined'|'voided', completedDateTime, signers: [...] }
Slack

Used by Agent 1 (Request Intake Agent) to send an acknowledgement to the requestor on ticket creation, and by Agent 3 (Procurement and Rollout Agent) to send the rollout notification to the requestor and named users.

Auth method
OAuth 2.0 bot token. Install the Slack app to the workspace with bot token scopes. Store the bot token as SLACK_BOT_TOKEN. Do not use legacy API tokens or webhook URLs for two-way interactions.
Required scopes
chat:write, chat:write.public (to post in channels without joining), users:read.email (to resolve requestor Slack user ID from form submission email address), im:write (to send direct messages to requestors).
Webhook / trigger setup
Slack is outbound-only in this automation. No inbound webhook or event subscription is required. Messages are dispatched via the Slack Web API POST /api/chat.postMessage. The requestor's Slack user ID is resolved at Agent 1 runtime using POST /api/users.lookupByEmail with the email captured in the intake form.
Required configuration
SLACK_ROLLOUT_CHANNEL_ID: the channel ID where rollout notifications are posted (e.g. #it-tools-rollout). SLACK_BOT_TOKEN: bot OAuth token. Message templates are defined in the orchestration layer config, not hardcoded in the workflow node. The rollout message must include: tool name, Jira ticket link, Notion register link, and onboarding materials URL (stored as ONBOARDING_DOCS_BASE_URL in the credential store).
Rate limits
Slack Web API: Tier 3 methods (chat.postMessage) allow 50 calls/minute. At 3 to 6 evaluations/month generating 2 Slack messages each, volume is negligible. No throttling required.
Constraints
users.lookupByEmail requires the users:read.email scope and will fail if the form submission email does not match a Slack workspace member. Implement a fallback: if no Slack user is found, post the acknowledgement to SLACK_ROLLOUT_CHANNEL_ID with the requestor's name and email in plain text. Never suppress the notification silently.
// Input (Agent 1 - acknowledgement DM)
POST /api/chat.postMessage
{ channel: requestor_slack_user_id, text: 'Your request for {tool_name} has been logged. Jira ticket: {jira_url}' }

// Input (Agent 3 - rollout notification)
POST /api/chat.postMessage
{
  channel: SLACK_ROLLOUT_CHANNEL_ID,
  blocks: [
    { type: 'section', text: '{tool_name} is approved and ready to use.' },
    { type: 'section', text: 'Onboarding docs: {ONBOARDING_DOCS_BASE_URL}/{tool_slug}' },
    { type: 'section', text: 'Software register: {notion_register_page_url}' }
  ]
}

// Output
{ ok: true, channel, ts, message: { text, bot_id } }

03Field mappings between tools

The following tables cover every agent handoff in the automation. Field names are shown in monospace using the exact property or API key name. Where a field is transformed or derived rather than directly mapped, a note is included in the destination field column.

Agent 1 handoff: Google Forms intake form to Jira ticket creation

Source tool
Source field
Destination tool
Destination field
Google Forms
`requestor_name`
Jira
`summary` (prepended: '[ITEVAL] Request: ')
Google Forms
`requestor_email`
Jira
`cf[requestor_email]`
Google Forms
`tool_name`
Jira
`cf[tool_name]`
Google Forms
`use_case`
Jira
`description` (body block 1)
Google Forms
`user_count`
Jira
`cf[user_count]`
Google Forms
`budget_range`
Jira
`cf[budget_range]`
Google Forms
`integration_needs`
Jira
`description` (body block 2)
Google Forms
`submission_timestamp`
Jira
`created` (auto-set by API)
Notion (duplicate check result)
`duplicate_match_url`
Jira
`cf[duplicate_flag]` ('yes' + Notion URL or 'no')

Agent 1 handoff: Google Forms intake form to Slack acknowledgement

Source tool
Source field
Destination tool
Destination field
Google Forms
`requestor_email`
Slack
`channel` (resolved via `users.lookupByEmail`)
Google Forms
`tool_name`
Slack
`text` (interpolated into message template)
Jira (created ticket)
`key`
Slack
`text` (Jira ticket link in message body)
Jira (created ticket)
`self`
Slack
`text` (full URL to ticket)

Agent 2 handoff: Jira ticket to Notion checklist and scorecard creation

Source tool
Source field
Destination tool
Destination field
Jira
`cf[tool_name]`
Notion
`Tool Name` (title property)
Jira
`key`
Notion
`Jira Ticket` (url property)
Jira
`cf[requestor_email]`
Notion
`Requestor` (email property)
Jira
`cf[use_case]`
Notion
`Use Case` (text property)
Jira
`cf[budget_range]`
Notion
`Budget Range` (text property)
Jira
`cf[user_count]`
Notion
`User Count` (number property)
Jira
`created`
Notion
`Request Date` (date property)

Agent 2 handoff: Notion scorecard completion to Gmail approval email

Source tool
Source field
Destination tool
Destination field
Notion
`Tool Name`
Gmail
`Subject` (interpolated: '[ITEVAL] Tool Approval Request: {tool_name}')
Notion
`Recommendation`
Gmail
`body` (approval summary section)
Notion
`Security Score`
Gmail
`body` (scorecard summary table)
Notion
`Integration Fit`
Gmail
`body` (scorecard summary table)
Notion
`Cost Rating`
Gmail
`body` (scorecard summary table)
Notion
`url` (page URL)
Gmail
`body` (link to full scorecard)
Jira
`key`
Gmail
`body` (link to Jira ticket)

Agent 3 handoff: Jira approval status to DocuSign envelope creation

Source tool
Source field
Destination tool
Destination field
Jira
`cf[tool_name]`
DocuSign
`customFields.tool_name`
Jira
`cf[budget_range]`
DocuSign
`customFields.monthly_cost` (parsed from range midpoint)
Notion
`Vendor` (from scorecard)
DocuSign
`templateRoles[vendor].name` + `customFields.vendor_name`
Notion
`Licence Count`
DocuSign
`customFields.licence_count`
Lifecycle config
`it_manager_name`
DocuSign
`templateRoles[it_signer].name`
Lifecycle config
`it_manager_email`
DocuSign
`templateRoles[it_signer].email`
Lifecycle config
`approval_date`
DocuSign
`customFields.approval_date`

Agent 3 handoff: DocuSign completion to Notion software register update

Source tool
Source field
Destination tool
Destination field
DocuSign
`envelopeId`
Notion
`Agreement ID` (text property)
DocuSign
`completedDateTime`
Notion
`Agreement Signed Date` (date property)
Jira
`cf[tool_name]`
Notion
`Tool Name` (title property)
Jira
`cf[budget_range]`
Notion
`Monthly Cost` (number property)
Jira
`cf[user_count]`
Notion
`Licence Count` (number property)
Lifecycle config
`it_manager_name`
Notion
`Owner` (person property, resolved by email)
Notion scorecard
`Request Date`
Notion
`Renewal Date` (date property, +12 months calculated)
Literal
'Active'
Notion
`Status` (select property)

Agent 3 handoff: DocuSign completion to Slack rollout notification

Source tool
Source field
Destination tool
Destination field
Jira
`cf[tool_name]`
Slack
`blocks[0].text` (tool name in message header)
Notion
`url` (register page URL)
Slack
`blocks[2].text` (software register link)
Orchestration config
`ONBOARDING_DOCS_BASE_URL`
Slack
`blocks[1].text` (onboarding docs link)
Jira
`cf[requestor_email]`
Slack
`channel` (DM to requestor, resolved via email lookup)
Integration and API SpecPage 2 of 3
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
One workflow per agent: Workflow 1 (Request Intake Agent), Workflow 2 (Evaluation and Approval Agent), Workflow 3 (Procurement and Rollout Agent). Each workflow is independently deployable and restartable. A shared credential store is referenced by all three workflows; no credentials are duplicated across workflow configs.
Workflow 1 trigger
Webhook (inbound): receives POST from Google Forms onFormSubmit Apps Script trigger. Alternatively, 5-minute poll against Google Forms API if webhook delivery is unreliable. Validate form submission schema on receipt before processing.
Workflow 2 trigger
Webhook (inbound) from Jira Cloud Automation rule firing on ticket transition to 'Evaluation In Progress'. Validate X-Atlassian-Token header. Poll fallback: every 5 minutes against Jira issue status endpoint. Polling also used internally to detect Notion checklist completion (15-minute interval) and Gmail approval reply (30-minute interval).
Workflow 3 trigger
Webhook (inbound) from Jira Cloud Automation rule firing on ticket transition to 'Approved' or 'Rejected'. Validate X-Atlassian-Token header. DocuSign Connect webhook (inbound) used to detect envelope completion; validate HMAC-SHA256 signature using DOCUSIGN_CONNECT_HMAC_KEY. Poll fallback for DocuSign: every 15 minutes.
Signature validation
Jira webhooks: validate X-Atlassian-Token matches JIRA_WEBHOOK_SECRET. DocuSign Connect: validate X-DocuSign-Signature-1 header as HMAC-SHA256(DOCUSIGN_CONNECT_HMAC_KEY, raw_body). Reject and log any webhook payload that fails signature validation; do not process.
Credential store
All secrets and environment-specific IDs are held in the platform's native secrets manager. No credential or ID value appears hardcoded in any workflow node. See code block below for the full credential store manifest.
Inter-workflow data passing
Jira is the shared state store between workflows. Workflow 1 writes all intake data to Jira custom fields. Workflow 2 reads from Jira and writes outputs back (Notion page URLs) to Jira ticket comments/fields. Workflow 3 reads from Jira and Notion. This avoids any direct workflow-to-workflow API coupling.
Execution environment
All workflows run on the hosted automation platform in a single environment per stage (sandbox and production). Retry and error handling logic is configured at the node level within each workflow, not at the platform scheduler level.
Credential store manifest: all keys required before any workflow is activated in production
// CREDENTIAL STORE MANIFEST
// All values populated before workflow activation.
// Never hardcode any of these in workflow nodes.

// Jira
JIRA_API_TOKEN          = '<api-token-for-service-account>'
JIRA_SERVICE_EMAIL      = '<service-account-email>@yourdomain.com'
JIRA_BASE_URL           = 'https://<your-org>.atlassian.net'
JIRA_PROJECT_KEY        = 'ITEVAL'
JIRA_EVALUATION_BOARD_ID = '<numeric-board-id>'
JIRA_WEBHOOK_SECRET     = '<shared-secret-for-header-validation>'
JIRA_FIELD_TOOL_NAME    = 'cf[<custom-field-id>]'
JIRA_FIELD_REQUESTOR_EMAIL = 'cf[<custom-field-id>]'
JIRA_FIELD_USE_CASE     = 'cf[<custom-field-id>]'
JIRA_FIELD_USER_COUNT   = 'cf[<custom-field-id>]'
JIRA_FIELD_BUDGET_RANGE = 'cf[<custom-field-id>]'
JIRA_FIELD_DUPLICATE_FLAG = 'cf[<custom-field-id>]'
JIRA_TRANSITION_INTAKE  = '<transition-id>'
JIRA_TRANSITION_IN_PROGRESS = '<transition-id>'
JIRA_TRANSITION_APPROVED = '<transition-id>'
JIRA_TRANSITION_REJECTED = '<transition-id>'

// Notion
NOTION_API_TOKEN        = 'secret_<integration-token>'
NOTION_SOFTWARE_REGISTER_DB_ID = '<uuid-of-software-register-db>'
NOTION_CHECKLIST_DB_ID  = '<uuid-of-checklist-db>'
NOTION_SCORECARD_DB_ID  = '<uuid-of-scorecard-db>'
NOTION_CHECKLIST_TEMPLATE_PAGE_ID = '<uuid-of-checklist-template>'
NOTION_SCORECARD_TEMPLATE_PAGE_ID = '<uuid-of-scorecard-template>'

// Google Workspace
GOOGLE_SERVICE_ACCOUNT_JSON = '<base64-encoded-service-account-key-json>'
GOOGLE_IMPERSONATION_EMAIL  = 'itmanager@yourdomain.com'
GOOGLE_FORM_ID          = '<google-form-resource-id>'
APPROVAL_EMAIL_TEMPLATE_SUBJECT = '[ITEVAL] Tool Approval Request: {tool_name}'
MANAGER_EMAIL           = 'manager@yourdomain.com'
REMINDER_DELAY_HOURS    = '48'

// DocuSign
DOCUSIGN_INTEGRATION_KEY   = '<client-id-from-docusign-app>'
DOCUSIGN_USER_ID           = '<impersonated-user-guid>'
DOCUSIGN_ACCOUNT_ID        = '<docusign-account-guid>'
DOCUSIGN_RSA_PRIVATE_KEY   = '<pem-encoded-rsa-private-key>'
DOCUSIGN_TEMPLATE_ID       = '<envelope-template-guid>'
DOCUSIGN_SIGNER_ROLE_VENDOR = 'Vendor Signatory'
DOCUSIGN_SIGNER_ROLE_IT    = 'IT Manager'
DOCUSIGN_SIGNER_ROLE_FINANCE = 'Finance Controller'
DOCUSIGN_CONNECT_HMAC_KEY  = '<hmac-secret-for-connect-validation>'
DOCUSIGN_ENV               = 'demo'  // change to 'production' at go-live

// Slack
SLACK_BOT_TOKEN         = 'xoxb-<bot-token>'
SLACK_ROLLOUT_CHANNEL_ID = 'C<channel-id>'

// General
ONBOARDING_DOCS_BASE_URL = 'https://notion.so/your-org/onboarding'
IT_MANAGER_NAME          = 'Marcus Dell'
IT_MANAGER_EMAIL         = 'marcus.dell@yourdomain.com'

05Error handling and retry logic

Every integration point has a defined failure behaviour. Unhandled exceptions must never fail silently. Any failure that cannot be resolved by retry must write a structured error log entry and notify the FullSpec support queue at support@gofullspec.com or the designated IT Manager via Slack DM.

Integration
Scenario
Required behaviour
Google Forms > Orchestration
Webhook delivery fails (Apps Script POST times out or returns non-200)
Poll fallback activates automatically on next 5-minute cycle. Log missed webhook event with timestamp. If poll also returns no new responses after 2 consecutive cycles, raise a Slack alert to IT Manager. Do not duplicate-process a response already handled.
Google Forms > Orchestration
Form submission payload is malformed or missing required fields
Reject the payload. Write a structured error log entry including the raw payload and timestamp. Send a Slack DM to IT Manager: 'Intake form submission received with missing fields. Manual review required.' Do not create a partial Jira ticket.
Jira (ticket creation)
Jira API returns 429 (rate limit) or 503 (service unavailable)
Retry with exponential backoff: 30s, 60s, 120s, 240s (four attempts). If all retries fail, log the error with the full form submission payload and send a Slack alert to IT Manager. The form submission payload must be stored so the ticket can be created manually or re-triggered.
Notion (duplicate check query)
Notion API returns 5xx or the database is unavailable
Retry twice with a 30-second delay. If both retries fail, proceed with ticket creation and set cf[duplicate_flag] to 'check-failed'. Log the failure. Post a note on the Jira ticket: 'Duplicate check could not be completed. Manual verification required.' Do not block ticket creation.
Jira webhook > Workflow 2
Workflow 2 webhook fails validation (X-Atlassian-Token mismatch)
Reject the request immediately. Log the IP, timestamp, and raw headers. Do not process. Alert IT Manager via Slack. If three validation failures occur within one hour, disable the webhook endpoint and require manual re-enablement.
Notion (checklist / scorecard creation)
Notion API returns 409 (conflict) or page already exists
Check whether a page for this Jira ticket key already exists in the target database before creating. If it exists, skip creation and link the existing page. If creation fails for any other reason, retry once after 60 seconds. On second failure, log and alert IT Manager to create the page manually.
Gmail (approval email send)
Gmail API returns 4xx (auth error or invalid recipient)
On 401/403: trigger OAuth token refresh and retry once. On 400 (invalid recipient): log the manager email address and alert IT Manager via Slack to confirm the correct email. Do not retry with an invalid address. On 429: retry after 60 seconds, once.
Gmail (approval reply detection)
No approval or rejection reply is detected within 48 hours
Send one reminder email to the manager using the same thread (In-Reply-To header set to original message ID). Log the reminder event in the Jira ticket as a comment. If no reply is detected within a further 48 hours (96 hours total), escalate via Slack DM to IT Manager and flag the Jira ticket as 'Approval Stalled'.
DocuSign (envelope creation)
DocuSign API returns 401 (JWT token expired or invalid)
Refresh the JWT Bearer token automatically (tokens expire after 1 hour). Retry the envelope creation once after refresh. If the refresh fails, log the error with full context and alert IT Manager via Slack. Do not leave the approval in a 'limbo' state; update Jira ticket comment with the failure status.
DocuSign (envelope completion detection)
Connect webhook delivery fails or HMAC validation fails
Poll fallback: check envelope status via GET /v2.1/accounts/{accountId}/envelopes/{envelopeId} every 15 minutes for envelopes in 'sent' status. On HMAC failure: reject, log, and alert IT Manager. Do not process unvalidated webhook payloads. If envelope status is 'declined' or 'voided': transition Jira to 'Rejected', notify requestor via Slack DM, and log the outcome.
Notion (software register update)
Notion API fails to create the new register entry after DocuSign completion
Retry twice with exponential backoff (30s, 90s). If both retries fail, log the full payload (all field values) and send an alert to IT Manager via Slack with the values to enter manually. Do not allow a signed agreement to result in a missing register entry. Mark the Jira ticket with a 'Register Update Failed' label.
Slack (any outbound message)
Slack API returns 4xx (invalid channel, user not found, or bot not in channel)
On users.lookupByEmail failure (user not found): fall back to posting in SLACK_ROLLOUT_CHANNEL_ID with requestor name and email in plain text. On channel not found: log and alert IT Manager via email (Gmail) as the last-resort fallback. Never suppress a notification silently. All Slack failures must be logged with the intended message content preserved.
Unhandled exceptions: any exception not covered by the scenarios above must be caught by a global error handler in each workflow. The global handler must: (1) log the exception type, message, stack context, and input payload to the platform error log; (2) send a Slack alert to the IT Manager channel with a summary; and (3) leave the Jira ticket in its current status with a comment indicating the failure. No workflow should exit without a logged outcome.
Integration and API SpecPage 3 of 3

More documents for this process

Every document generated for New Tool Evaluation & Rollout.

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