Back to Probation Period 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

Probation Period Management

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

This document specifies every integration point, authentication method, required scope, field mapping, and error-handling behaviour for the Probation Period Management automation. It is written for the FullSpec build team and covers BambooHR, Notion, Google Workspace, Slack, and DocuSign as connected tools alongside the orchestration layer. Nothing in this document should be treated as advisory: all configuration values, scope strings, and retry rules are requirements. Where credentials are referenced, they must be stored in the shared credential store and never hardcoded into workflow logic.

01Tool inventory

Tool
Role in automation
Auth method
Min plan required
Used by agent(s)
BambooHR
Source of truth for employee records; trigger source and final write-back destination
OAuth 2.0 (API key per subdomain)
Essentials or higher (API access included)
Agent 1, Agent 3
Notion
Probation tracker: milestone log, outcome recording, and row closure
OAuth 2.0 (Notion integration token)
Plus or Business (API access on all paid plans)
Agent 1, Agent 2, Agent 3
Google Workspace (Gmail + Drive + Docs)
Feedback request emails, outcome letter template source, signed file storage
OAuth 2.0 (service account with domain-wide delegation)
Business Starter or higher
Agent 2, Agent 3
Slack
48-hour escalation reminder to managers and HR escalation alerts
OAuth 2.0 (Slack app bot token)
Pro or higher (free tier may block DMs from bots)
Agent 2
DocuSign
Sequential envelope creation, signing routing (manager then employee), completion webhook
OAuth 2.0 (JWT grant with RSA key pair)
Standard or higher (API access required)
Agent 3
Orchestration layer (automation platform)
Hosts all three agent workflows; manages credentials, scheduling, retries, and inter-agent handoffs
Internal credential store; per-connection OAuth tokens
Team/Business tier with multi-step workflows and webhook support
All agents
Before you connect anything: all five tool connections must be validated in a sandbox or developer environment before any production credentials are entered. BambooHR, DocuSign, and Notion each offer sandbox/test environments. Google Workspace service accounts should be scoped and tested against a non-production Google Workspace domain alias first. Slack bot tokens should be installed into a dedicated test workspace. Production credentials must not appear in workflow logic, environment variable logs, or version-controlled config files at any point.

02Per-tool integration detail

BambooHR

BambooHR is the trigger source for Agent 1 (new employee record detection) and the write-back destination for Agent 3 (final probation outcome update). The API uses subdomain-scoped API keys issued per user account. The integration must use a dedicated service account, not a named employee account, so that credential rotation does not depend on HR staff.

Auth method
HTTP Basic Auth over HTTPS using a generated API key. Key is tied to the BambooHR subdomain (e.g. api.bamboohr.com/api/gateway.php/{subdomain}/v1/). Store the API key and subdomain slug in the credential store as BAMBOOHR_API_KEY and BAMBOOHR_SUBDOMAIN.
Required scopes
BambooHR uses permission levels rather than OAuth scopes. The service account must be assigned the 'API Access' permission set in BambooHR Admin > Access Levels. Required field-level access: Employee Read (all fields including custom fields), Employee Write (for probation_status and probation_outcome fields). No payroll or benefits access is required.
Webhook / trigger setup
Agent 1 polls the BambooHR Employee endpoint at a 15-minute interval. Endpoint: GET /v1/employees/changed?since={last_run_timestamp}&type=inserted. Filter response for records where the field hireDate is not null and employment_status equals 'Active'. BambooHR does not natively push webhooks for new employee creation on most plans, so polling is the required trigger mechanism.
Required configuration
The following BambooHR custom fields must exist before build starts: probation_end_date (date field), probation_status (list: Active, Extended, Passed, Exited), probation_outcome (text). These field IDs must be retrieved from GET /v1/meta/fields and stored as BAMBOOHR_FIELD_PROBATION_END_DATE_ID, BAMBOOHR_FIELD_PROBATION_STATUS_ID, and BAMBOOHR_FIELD_PROBATION_OUTCOME_ID in the credential store. Do not hardcode numeric field IDs.
Rate limits
BambooHR enforces a rate limit of approximately 500 requests per hour per API key. At 3 to 5 hires per month, polling every 15 minutes produces approximately 96 requests per day. No throttling is required at current volume. Build a simple counter log to alert if request rate approaches 400/hour.
Constraints
The API does not support bulk employee writes. Each BambooHR update (Agent 3 write-back) must be a separate PATCH request per employee. HTTPS is mandatory; plaintext HTTP requests will be rejected. The subdomain slug is case-sensitive.
// Agent 1 Trigger Poll
GET /api/gateway.php/{BAMBOOHR_SUBDOMAIN}/v1/employees/changed
  ?since={last_run_iso8601}
  &type=inserted
  Authorization: Basic base64(BAMBOOHR_API_KEY:x)

// Agent 3 Outcome Write-back
PATCH /api/gateway.php/{BAMBOOHR_SUBDOMAIN}/v1/employees/{employee_id}
  Body: { "probation_status": "Passed", "probation_outcome": "Confirmed" }
Notion

Notion serves as the central probation tracker across all three agents. Agent 1 creates rows, Agent 2 reads milestone dates and writes chase log entries, and Agent 3 reads the logged outcome and closes the row. All Notion access goes through a single internal integration token scoped to the HR workspace.

Auth method
Notion internal integration token (Bearer token). Created at notion.so/my-integrations and shared with the target database. Store as NOTION_INTEGRATION_TOKEN. The integration must be explicitly shared with each Notion database it accesses.
Required scopes
read_content, update_content, insert_content. These are selected at integration creation time in the Notion UI. The integration does not require user or workspace-level admin access.
Webhook / trigger setup
Agent 3 is triggered by a Notion database property change: HR Manager sets the 'outcome' select field on a probation row. The orchestration layer polls the Notion database endpoint every 5 minutes for rows where outcome is not empty and docusign_sent equals false. Notion does not currently provide native webhooks for database changes; polling is required. Filter: GET /v1/databases/{NOTION_DB_PROBATION_ID}/query with filter on property 'outcome' is not empty AND property 'docusign_sent' equals false.
Required configuration
The probation tracker database must contain the following properties before build: employee_name (title), employee_id (text), manager_email (email), manager_slack_id (text), start_date (date), milestone_4w (date), milestone_8w (date), probation_end_date (date), outcome (select: Pass, Extend, Exit), docusign_sent (checkbox), docusign_envelope_id (text), record_closed (checkbox), chase_log (text). Store the database ID as NOTION_DB_PROBATION_ID in the credential store.
Rate limits
Notion API rate limit is 3 requests per second averaged over one minute. At current volume (3 to 5 hires/month), polling every 5 minutes across all agents produces well under 50 requests per minute. No throttling needed. Build exponential backoff on 429 responses.
Constraints
The Notion integration token is workspace-specific. If the Notion workspace is migrated or the database is moved to a different workspace, the token must be regenerated and the database re-shared. Database property names are case-sensitive in API queries. Property type changes (e.g. text to select) will break existing filter queries silently.
// Agent 1 creates a new tracker row
POST /v1/pages
  parent: { database_id: NOTION_DB_PROBATION_ID }
  properties: { employee_name, employee_id, manager_email,
    start_date, milestone_4w, milestone_8w, probation_end_date }

// Agent 3 polls for outcome-logged rows
POST /v1/databases/{NOTION_DB_PROBATION_ID}/query
  filter: { and: [ outcome is_not_empty, docusign_sent = false ] }

// Agent 3 closes the row after DocuSign completion
PATCH /v1/pages/{page_id}
  properties: { record_closed: true, docusign_envelope_id: "..." }
Google Workspace (Gmail + Google Drive + Google Docs)

Google Workspace covers three distinct integration points: Gmail for sending milestone feedback request emails (Agent 2), Google Docs for populating outcome letter templates (Agent 3), and Google Drive for storing the completed pre-signature letter PDF (Agent 3). A single service account with domain-wide delegation covers all three.

Auth method
OAuth 2.0 service account with domain-wide delegation. The service account JSON key file is stored as GOOGLE_SERVICE_ACCOUNT_JSON in the credential store. The service account must be granted domain-wide delegation in Google Workspace Admin > Security > API Controls, and the scopes below must be explicitly authorised.
Required scopes
https://www.googleapis.com/auth/gmail.send (send emails as the HR service address), https://www.googleapis.com/auth/documents (read and write Google Docs), https://www.googleapis.com/auth/drive (upload and manage files in Drive). Impersonation subject must be set to the HR service email address (stored as GOOGLE_IMPERSONATION_EMAIL).
Webhook / trigger setup
No inbound webhook from Google Workspace is required. Agent 2 sends outbound emails via the Gmail API. Agent 3 reads a specific template Docs file and writes a copy. Drive is write-only from the automation's perspective.
Required configuration
Three Google Docs template files must exist before build: GDOC_TEMPLATE_PASS_ID, GDOC_TEMPLATE_EXTEND_ID, GDOC_TEMPLATE_EXIT_ID. Each template must use the following placeholder strings exactly: {{employee_full_name}}, {{outcome_date}}, {{manager_name}}, {{extension_end_date}} (extend template only), {{company_name}}. Template IDs are stored in the credential store. The destination Drive folder ID for completed letters must be stored as GDRIVE_OUTCOME_FOLDER_ID. Gmail send-as address must be authorised for the service account subject.
Rate limits
Gmail API: 250 quota units per user per second; sending one email per milestone per hire at current volume produces under 20 emails per day. No throttling required. Google Docs API: 300 requests per minute per project. Drive API: 1,000 requests per 100 seconds. Both are well within limits at current volume. Implement retry on 429 and 503 responses with 60-second initial backoff.
Constraints
Google Docs template files must be locked (editors restricted) before go-live. The automation uses whichever version is live at run time; an uncontrolled edit will affect all subsequent letters. Drive file export to PDF uses the Google Drive export endpoint, not a third-party PDF library. The exported PDF must be base64-encoded before passing to DocuSign.
// Agent 2: Send milestone feedback email
POST https://gmail.googleapis.com/gmail/v1/users/me/messages/send
  Authorization: Bearer {access_token}
  Body: RFC 2822 encoded message with To, Subject, body (HTML)

// Agent 3: Copy template and populate placeholders
POST https://docs.googleapis.com/v1/documents/{GDOC_TEMPLATE_PASS_ID}:copy
  -> returns new_doc_id
POST https://docs.googleapis.com/v1/documents/{new_doc_id}:batchUpdate
  replaceAllText: [ { {{employee_full_name}} -> value }, ... ]

// Agent 3: Export populated doc as PDF
GET https://www.googleapis.com/drive/v3/files/{new_doc_id}/export
  ?mimeType=application/pdf
Integration and API SpecPage 1 of 4
FS-DOC-05Technical
Slack

Slack is used exclusively by Agent 2 (Feedback Chase Agent) to deliver direct message reminders to managers who have not submitted feedback within 48 hours of a milestone email being sent. A secondary escalation message is sent to the HR channel if the manager does not respond after the first Slack reminder.

Auth method
OAuth 2.0 bot token. A Slack app is created in the Slack API dashboard, installed to the workspace, and the bot token is stored as SLACK_BOT_TOKEN. The app does not require user token scope for this process.
Required scopes
chat:write (post messages as the bot), im:write (open direct message channels with users), users:read (look up user ID by email), users:read.email (required to resolve manager_email to a Slack user ID). The bot must be invited to the HR escalation channel (stored as SLACK_HR_CHANNEL_ID).
Webhook / trigger setup
No inbound webhook from Slack is used. All Slack interactions are outbound API calls triggered by the 48-hour timer logic within Agent 2. Manager replies are not parsed by the automation; the feedback submission path is via Gmail/Google Form, not Slack reply.
Required configuration
The HR escalation Slack channel ID must be stored as SLACK_HR_CHANNEL_ID. The bot must be added to this channel before go-live. Manager Slack user IDs are resolved at runtime using the users.lookupByEmail endpoint against the manager_email field from Notion. If a manager email does not resolve to a Slack user, the system falls back to a second Gmail chase and logs the Slack failure in the Notion chase_log field.
Rate limits
Slack API Tier 3 rate limit: 50 requests per minute for chat.postMessage. At 3 to 5 hires per month with up to two Slack messages per hire milestone, the automation produces fewer than 30 Slack API calls per month. No throttling required. Implement retry with 30-second backoff on 429 responses.
Constraints
The bot token must be re-authorised if the Slack app is uninstalled and reinstalled. Slack user IDs change only if a user is deactivated and recreated; email lookup is the reliable resolution method. The bot cannot send messages to private channels it has not been explicitly invited to. All message text must comply with Slack's block kit formatting if rich text is used; plain text fallback must always be included.
// Resolve manager email to Slack user ID
GET https://slack.com/api/users.lookupByEmail?email={manager_email}
  Authorization: Bearer SLACK_BOT_TOKEN
  -> returns user.id

// Open DM channel and post reminder
POST https://slack.com/api/conversations.open
  { users: [user_id] } -> returns channel.id
POST https://slack.com/api/chat.postMessage
  { channel: channel_id, text: "Reminder: probation feedback due for {employee_name}" }

// HR escalation if second reminder ignored
POST https://slack.com/api/chat.postMessage
  { channel: SLACK_HR_CHANNEL_ID, text: "Escalation: {manager_name} has not submitted feedback..." }
DocuSign

DocuSign is used by Agent 3 (Outcome and Documentation Agent) to create and send a sequential signing envelope: the manager signs first, then the employee. The automation polls for envelope completion and, on a completed status, retrieves the signed PDF, stores it in Google Drive, and triggers the BambooHR write-back. DocuSign JWT grant is the required auth method as the integration acts on behalf of a service user, not an interactive session.

Auth method
OAuth 2.0 JWT Bearer Grant using an RSA key pair. The private key is stored as DOCUSIGN_RSA_PRIVATE_KEY in the credential store. The integration key (client ID) is stored as DOCUSIGN_INTEGRATION_KEY. The impersonated user GUID (the HR service account user in DocuSign) is stored as DOCUSIGN_USER_GUID. JWT tokens are short-lived (1 hour) and must be refreshed automatically by the orchestration layer.
Required scopes
signature (create and send envelopes on behalf of the impersonated user), impersonation (required for JWT grant to act as the service user). These scopes must be granted by a DocuSign administrator in the app configuration under Apps and Keys.
Webhook / trigger setup
DocuSign Connect (webhook) must be configured to notify the orchestration layer when an envelope reaches 'completed' status. The webhook endpoint URL must be set in DocuSign Admin > Connect > Add Configuration. The endpoint is provided by the orchestration platform and stored as DOCUSIGN_CONNECT_WEBHOOK_URL. Signature validation: DocuSign signs the Connect payload with an HMAC-SHA256 key stored as DOCUSIGN_CONNECT_HMAC_KEY. The orchestration layer must validate this signature on every inbound Connect event before processing.
Required configuration
The signing order must be configured on every envelope: recipient 1 = manager (routingOrder: 1), recipient 2 = employee (routingOrder: 2). Manager and employee email addresses are sourced from the Notion tracker row at runtime. The DocuSign account ID is stored as DOCUSIGN_ACCOUNT_ID. The base URI for API calls (e.g. na3.docusign.net) is stored as DOCUSIGN_BASE_URI and must be retrieved from the userinfo endpoint at JWT token exchange time, not hardcoded.
Rate limits
DocuSign Standard plan allows 100 envelopes per month included, with overages billed per envelope. At 3 to 5 hires per month, maximum 5 envelopes per month are produced. No rate throttling is required. The eSign API enforces a burst limit of 1,000 API calls per hour per account; current volume produces under 50 calls per month.
Constraints
JWT consent must be granted interactively by a DocuSign admin before the first automated JWT token request will succeed. The RSA private key must be stored securely and must not appear in workflow export files or logs. If the employee's email address in BambooHR is not yet populated at letter generation time, Agent 3 must pause and alert HR via Slack before sending the envelope. The signed PDF retrieved from DocuSign after completion must be stored in Google Drive within the same Agent 3 execution run.
// JWT token exchange
POST https://account.docusign.com/oauth/token
  grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
  assertion={signed_jwt}
  -> access_token (1 hr expiry)

// Create and send envelope
POST https://{DOCUSIGN_BASE_URI}/restapi/v2.1/accounts/{DOCUSIGN_ACCOUNT_ID}/envelopes
  { status: 'sent', documents: [{documentBase64: pdf_b64}],
    recipients: { signers: [
      { email: manager_email, routingOrder: 1 },
      { email: employee_email, routingOrder: 2 }
    ] } }

// Inbound Connect webhook (validate HMAC before processing)
POST {DOCUSIGN_CONNECT_WEBHOOK_URL}
  Header: X-DocuSign-Signature-1: {hmac_sha256}
  Body: { envelopeId, status: 'completed', ... }

// Retrieve signed document after completion
GET /restapi/v2.1/accounts/{DOCUSIGN_ACCOUNT_ID}/envelopes/{envelope_id}/documents/combined

03Field mappings between tools

The following tables cover every inter-tool field handoff across the three agent boundaries. Field names are shown exactly as they appear in each tool's API response or request body. All date values are ISO 8601 (YYYY-MM-DD) unless stated otherwise.

Agent 1 handoff: BambooHR to Notion (Probation Schedule Agent creates the tracker row)

Source tool
Source field
Destination tool
Destination field
BambooHR
id
Notion
employee_id
BambooHR
firstName + lastName
Notion
employee_name
BambooHR
workEmail
Notion
manager_email (resolved via supervisor lookup)
BambooHR
hireDate
Notion
start_date
BambooHR
hireDate + 28 days (calculated)
Notion
milestone_4w
BambooHR
hireDate + 56 days (calculated)
Notion
milestone_8w
BambooHR
custom: probation_end_date
Notion
probation_end_date
BambooHR
supervisorEmail
Notion
manager_email
BambooHR
displayName (supervisor)
Notion
manager_slack_id (resolved via Slack users.lookupByEmail at runtime)

Agent 2 handoff: Notion to Gmail and Slack (Feedback Chase Agent reads milestone dates and manager contact details)

Source tool
Source field
Destination tool
Destination field
Notion
employee_name
Gmail
email body placeholder: {{employee_full_name}}
Notion
manager_email
Gmail
To: header
Notion
milestone_4w / milestone_8w / probation_end_date
Gmail
email body placeholder: {{review_date}}
Notion
employee_id
Gmail
email body: feedback form URL query param ?eid={{employee_id}}
Notion
manager_slack_id
Slack
users.lookupByEmail -> channel open -> chat.postMessage channel
Notion
employee_name
Slack
message text placeholder: {employee_name}
Notion
chase_log (append)
Notion
chase_log (updated on each send with ISO 8601 timestamp + action)

Agent 3 handoff: Notion to Google Docs, DocuSign, and BambooHR (Outcome and Documentation Agent generates letter, routes for signing, and writes outcome back)

Source tool
Source field
Destination tool
Destination field
Notion
outcome (Pass/Extend/Exit)
Google Docs
template selection logic (GDOC_TEMPLATE_PASS_ID / EXTEND / EXIT)
Notion
employee_name
Google Docs
replaceAllText: {{employee_full_name}}
Notion
probation_end_date
Google Docs
replaceAllText: {{outcome_date}}
Notion
manager_email (supervisor name resolved via BambooHR)
Google Docs
replaceAllText: {{manager_name}}
Notion
outcome = Extend -> extension_end_date (date field)
Google Docs
replaceAllText: {{extension_end_date}}
Google Drive (exported PDF)
file binary (base64-encoded)
DocuSign
documents[0].documentBase64
Notion
manager_email
DocuSign
recipients.signers[0].email (routingOrder: 1)
BambooHR
workEmail (employee)
DocuSign
recipients.signers[1].email (routingOrder: 2)
DocuSign
envelopeId (from create response)
Notion
docusign_envelope_id
DocuSign
status: completed (Connect webhook)
Notion
record_closed = true
DocuSign
status: completed
BambooHR
custom: probation_status (Passed/Extended/Exited)
Notion
outcome
BambooHR
custom: probation_outcome (free text confirmation string)
DocuSign
combined signed PDF (binary)
Google Drive
file upload to GDRIVE_OUTCOME_FOLDER_ID
Integration and API SpecPage 2 of 4
FS-DOC-05Technical

04Build stack and orchestration

Orchestration layout
Three discrete workflows, one per agent. Each workflow is independently deployable and versioned. Workflows share a single credential store; no credentials are duplicated across workflow definitions. Inter-agent communication is state-based via the Notion probation tracker database: Agent 1 writes, Agent 2 reads and appends, Agent 3 reads and closes.
Agent 1 trigger mechanism
Poll. The Probation Schedule Agent polls BambooHR GET /v1/employees/changed every 15 minutes. The poll stores a last_run_timestamp in the orchestration state between executions. On match (new employee record with hireDate populated), the workflow runs once per matching record and marks the record as processed using a Notion row creation as the idempotency check.
Agent 2 trigger mechanism
Schedule + poll. The Feedback Chase Agent runs on a daily schedule at 08:00 in the configured timezone. It queries the Notion tracker for rows where milestone dates fall on or before today and where feedback has not been received (no Google Form response linked). A secondary timer fires at 08:00 the day after a milestone to check the 48-hour window and trigger the Slack reminder if still no response.
Agent 3 trigger mechanism
Poll with webhook overlay. The Outcome and Documentation Agent polls Notion every 5 minutes for rows where outcome is not empty and docusign_sent is false. This covers the letter generation and envelope send. The DocuSign Connect webhook (inbound) handles the signing completion event independently. The webhook payload is validated via HMAC-SHA256 before any downstream action is taken. Signature: X-DocuSign-Signature-1 header compared against HMAC-SHA256(DOCUSIGN_CONNECT_HMAC_KEY, raw_body_bytes).
Credential store contents
See code block below. All values are injected as environment variables or secrets at runtime. No credential value appears in workflow node configuration fields, export files, or version history.
Idempotency controls
Agent 1: Notion row creation is idempotent by employee_id check before insert. Agent 2: chase_log field records ISO 8601 timestamps of every send; the workflow checks the log before sending to prevent duplicate emails or Slack messages within the same milestone window. Agent 3: docusign_sent boolean on the Notion row prevents duplicate envelope creation; DocuSign envelopeId is written to Notion immediately after envelope creation.
Timezone handling
All milestone dates are stored and compared in UTC. The orchestration layer converts milestone dates to the configured local timezone (stored as ORG_TIMEZONE) only when populating email and letter content. BambooHR hireDate is treated as a date-only value with no time component.
Credential store: all entries are secrets. Never log, export, or embed these values in workflow configuration.
// Credential store contents (all values injected at runtime as secrets)

// BambooHR
BAMBOOHR_API_KEY                    = <api_key_from_bamboohr_admin>
BAMBOOHR_SUBDOMAIN                  = <your_subdomain>  // e.g. 'yourcompany'
BAMBOOHR_FIELD_PROBATION_END_DATE_ID = <custom_field_id>  // from GET /v1/meta/fields
BAMBOOHR_FIELD_PROBATION_STATUS_ID  = <custom_field_id>
BAMBOOHR_FIELD_PROBATION_OUTCOME_ID = <custom_field_id>

// Notion
NOTION_INTEGRATION_TOKEN            = <secret_xxx_token>
NOTION_DB_PROBATION_ID              = <database_id_from_notion_url>

// Google Workspace
GOOGLE_SERVICE_ACCOUNT_JSON         = <json_key_file_contents>  // base64-encoded recommended
GOOGLE_IMPERSONATION_EMAIL          = hr-automation@yourcompany.com
GDOC_TEMPLATE_PASS_ID               = <google_doc_id>
GDOC_TEMPLATE_EXTEND_ID             = <google_doc_id>
GDOC_TEMPLATE_EXIT_ID               = <google_doc_id>
GDRIVE_OUTCOME_FOLDER_ID            = <google_drive_folder_id>

// Slack
SLACK_BOT_TOKEN                     = xoxb-<bot_token>
SLACK_HR_CHANNEL_ID                 = C<channel_id>  // #hr-escalations

// DocuSign
DOCUSIGN_INTEGRATION_KEY            = <client_id_from_docusign_apps_and_keys>
DOCUSIGN_RSA_PRIVATE_KEY            = <pem_private_key>  // stored as multiline secret
DOCUSIGN_USER_GUID                  = <user_guid_of_hr_service_account>
DOCUSIGN_ACCOUNT_ID                 = <account_id>
DOCUSIGN_BASE_URI                   = na3.docusign.net  // retrieved from userinfo; do not hardcode without verification
DOCUSIGN_CONNECT_HMAC_KEY           = <connect_hmac_secret>
DOCUSIGN_CONNECT_WEBHOOK_URL        = <orchestration_platform_inbound_url>

// Organisation config
ORG_TIMEZONE                        = America/New_York  // replace with actual org timezone
COMPANY_NAME                        = [YourCompany.com]

05Error handling and retry logic

Unhandled exceptions must never fail silently. Every integration point in this automation must have a defined failure path. If a retry sequence is exhausted without success, the workflow must write a failure record to the Notion chase_log field and post an alert to SLACK_HR_CHANNEL_ID with the agent name, the failing step, and the affected employee_id. A silent failure in this process risks a probation period lapsing without documentation, which carries direct legal and employment risk.
Integration
Scenario
Required behaviour
BambooHR (Agent 1 poll)
Poll returns HTTP 401 (invalid or expired API key)
Halt workflow. Post alert to SLACK_HR_CHANNEL_ID with error details. Do not retry until credential is confirmed valid. Raise to FullSpec support@gofullspec.com.
BambooHR (Agent 1 poll)
Poll returns HTTP 429 (rate limit exceeded)
Wait 60 seconds then retry up to 3 times with exponential backoff (60s, 120s, 240s). If all retries fail, log to orchestration error log and skip cycle; resume at next scheduled poll.
BambooHR (Agent 1 poll)
Custom field ID not found in employee record (field not yet configured in BambooHR admin)
Halt Agent 1 for that record. Write error entry to Notion chase_log (if row exists) or to a separate error log database. Alert SLACK_HR_CHANNEL_ID. Do not create incomplete Notion row.
Notion (Agent 1 write)
Notion API returns 503 or times out during row creation
Retry up to 3 times with 30-second backoff. If all retries fail, write the pending row data to the orchestration platform's internal retry queue and attempt again at the next Agent 1 poll cycle. Alert HR channel after second failed attempt.
Notion (Agent 2 poll / Agent 3 poll)
Notion database property schema has changed (e.g. field renamed or type changed)
Workflow will receive a schema mismatch error or empty result. Halt the affected agent. Post alert to SLACK_HR_CHANNEL_ID with property name and error. Do not attempt partial writes. Requires manual schema correction and workflow re-validation before resuming.
Gmail (Agent 2 send)
Gmail API returns 429 (quota exceeded) or 503
Retry up to 3 times with 60-second backoff. If all retries fail, log the unsent email event in Notion chase_log with timestamp and status 'email_failed'. Alert SLACK_HR_CHANNEL_ID so HR can send manually. Do not skip without logging.
Slack (Agent 2 reminder)
users.lookupByEmail returns no match (manager not in Slack workspace)
Fall back to a second Gmail reminder email to manager_email. Log 'slack_user_not_found' in Notion chase_log. Do not block the feedback chase flow; the email fallback is the continuity path.
Slack (Agent 2 reminder)
chat.postMessage returns HTTP 400 (channel not found or bot not invited)
Log error to orchestration error log. Attempt Gmail fallback immediately. If Gmail also fails, post raw alert to SLACK_HR_CHANNEL_ID via a separate minimal bot call. If that also fails, email GOOGLE_IMPERSONATION_EMAIL directly as last resort.
Google Docs (Agent 3 template merge)
Template document ID not found in Drive (file deleted or moved)
Halt Agent 3 for that hire. Do not send a DocuSign envelope with a blank or wrong document. Post alert to SLACK_HR_CHANNEL_ID with the missing template ID and outcome type. HR must restore the template and re-trigger by clearing docusign_sent and outcome fields in Notion.
DocuSign (Agent 3 envelope create)
Employee email not populated in BambooHR at time of envelope creation
Halt envelope creation. Post alert to SLACK_HR_CHANNEL_ID: 'DocuSign envelope blocked: employee email missing for {employee_name}'. Write 'envelope_blocked_no_email' to Notion chase_log. Retry automatically once per hour for up to 24 hours; if still unresolved, escalate to HR for manual data entry.
DocuSign Connect (Agent 3 completion webhook)
Inbound webhook HMAC signature validation fails
Reject the request with HTTP 400. Log the raw request headers and timestamp to the orchestration security log. Do not process envelope completion or trigger BambooHR write-back. Alert SLACK_HR_CHANNEL_ID. Investigate for replay attack or misconfigured HMAC key before re-enabling.
BambooHR (Agent 3 write-back)
PATCH request to update probation_status fails after DocuSign completion
Retry up to 3 times with 30-second backoff. If all retries fail, mark Notion row with status 'bamboohr_update_failed' and alert SLACK_HR_CHANNEL_ID so HR can perform the HRIS update manually. The signed PDF is already stored in Google Drive; this failure does not affect the signed document.
Integration and API SpecPage 3 of 4
FS-DOC-05Technical
All error alerts posted to Slack must include: agent name, affected employee_id, step name, error code or message, and a timestamp. This ensures HR can triage any failure without accessing the orchestration platform directly. The FullSpec team reviews error logs weekly during the first month post-launch and monthly thereafter. For urgent issues, contact support@gofullspec.com.
Integration and API SpecPage 4 of 4

More documents for this process

Every document generated for Probation Period 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