Back to New Tool Evaluation & Rollout

Developer Handover Pack

Everything needed to build the automation from scratch: current state, full agent specs, data flow, and the build stack.

4 pagesPDF · Technical
FS-DOC-04Technical

Developer Handover Pack

New Tool Evaluation & Rollout

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

This document is the authoritative technical reference for the three-agent New Tool Evaluation and Rollout automation. It covers the current-state process map, full agent specifications with IO contracts, end-to-end data flow, and the recommended build stack. The FullSpec team uses this pack to build and test the automation from scratch. No external developer or third-party agency is involved. Where this document specifies field names, status values, or API behaviours, those specifications govern the build.

01Process snapshot

Step
Name
Description
1
Receive and Log Tool Request
A staff member emails, messages, or verbally raises a request. IT Manager manually records it in a spreadsheet or Jira board. (15 min)
2 BOTTLENECK
Clarify Requirements with Requestor
IT follows up via email or Slack to gather use case, user count, budget, and integrations. Back-and-forth often takes days. (30 min active; up to several days elapsed)
3
Check for Existing or Duplicate Tools
IT searches the Notion software register to see if an existing tool covers the need. Register is often out of date. (20 min)
4 BOTTLENECK
Conduct Initial Security and Compliance Review
IT reviews vendor security posture, data handling, and compliance requirements such as GDPR or SOC 2. Notes saved informally and step is frequently skipped. (45 min)
5
Request Vendor Demo or Trial Access
IT or requestor contacts the vendor to arrange a demo or free trial. Scheduling is manual. (20 min)
6
Complete Evaluation Scorecard
IT and stakeholders score the tool against cost, integration fit, support quality, and security using a shared Google Sheet. (40 min)
7 BOTTLENECK
Route for Management Approval
IT emails evaluation summary to the relevant manager or finance contact. Follow-up reminders are sent manually and requests frequently stall. (15 min active; 5-10 days elapsed)
8
Obtain Signed Agreement or Purchase Order
IT or finance progresses the contract or PO. Documents are emailed back and forth for signatures via DocuSign. (25 min)
9
Provision Licences and Configure Access
IT sets up the tool, provisions user accounts, and configures SSO or directory integration. HUMAN STEP RETAINED. (35 min)
10
Notify Users and Share Onboarding Materials
IT or requestor notifies intended users and shares setup guides, training links, or internal documentation via Slack. (20 min)
11
Update Software Register
IT adds the new tool to the master software register in Notion with licence count, renewal date, cost, and owner. (15 min)
Time cost summary: Total manual time per evaluation cycle is 280 minutes (4 hours 40 min) of active IT effort, plus substantial elapsed waiting time at steps 2 and 7. At approximately 3 to 6 evaluations per month, this equates to roughly 4.5 hours of active manual work per week. The automation replaces steps 1, 2, 3 (Request Intake Agent), steps 4, 5, 6, 7 (Evaluation and Approval Agent), and steps 8, 10, 11 (Procurement and Rollout Agent). Step 9 (licence provisioning and SSO configuration) is retained as a human task requiring hands-on system access.
Developer Handover PackPage 1 of 4
FS-DOC-04Technical

02Agent specifications

Request Intake Agent

Receives the structured intake form submission, creates a Jira ticket with all captured request fields, queries the Notion software register for duplicate or overlapping tools, flags any match on the Jira ticket, and posts an acknowledgement message to the requestor in Slack. This agent eliminates the unstructured multi-channel request intake and the informal manual duplicate check. All intake data is normalised at this stage and carried forward as the canonical record for the evaluation.

Trigger
New tool request form submitted (webhook from Google Workspace form or equivalent intake form)
Tools
Jira, Notion, Slack
Replaces steps
Steps 1, 2, and 3
Estimated build
8 hours / Moderate complexity
// Input
form.requestor_name        : string
form.requestor_email       : string
form.tool_name             : string
form.use_case              : string
form.user_count            : integer
form.budget_range          : string
form.integrations_needed   : string[]
form.submitted_at          : ISO8601 timestamp

// Output
jira.ticket_id             : string   // e.g. IT-204
jira.ticket_status         : string   // 'Intake Received'
jira.duplicate_flag        : boolean  // true if Notion match found
jira.duplicate_tool_name   : string   // populated if duplicate_flag = true
slack.ack_message_ts       : string   // Slack message timestamp for threading
  • Jira tier required: Jira Software Cloud (Standard or above) to access the REST API v3. Project key must be confirmed before build (e.g. 'IT'). Issue type must be 'Task' or a custom 'Tool Request' type, confirmed with the IT Manager before field mapping.
  • Notion duplicate check: query the 'Software Register' database using the tool_name field against the 'Tool Name' property. Use a contains filter, not an exact-match filter, to catch partial name overlaps. The Notion database ID must be captured during stack audit and stored as an environment variable (NOTION_SOFTWARE_REGISTER_DB_ID).
  • If the Notion software register contains inconsistently formatted entries, the duplicate check will return false negatives. The register must be cleaned and standardised before this agent goes live. This is a confirmed pre-build dependency.
  • Slack acknowledgement must be sent to the requestor's Slack user ID, resolved from form.requestor_email via the Slack users.lookupByEmail API method. If no Slack account is found for that email, fall back to posting to a designated #it-requests channel and tagging the email address in the message body.
  • Deduplication: if duplicate_flag is true, the Jira ticket is created and flagged but the workflow does not proceed to the Evaluation and Approval Agent automatically. IT Manager reviews and closes the ticket manually (retained human decision point).
  • The intake form must include all fields listed in the Input block above. Any optional fields must still be submitted as empty strings to prevent null-handling errors downstream.
Evaluation and Approval Agent

Triggered when the Jira ticket status transitions to 'Evaluation In Progress', this agent generates a pre-built security checklist and a standardised evaluation scorecard in Notion, both pre-populated with the request details from the Jira ticket. It monitors Notion for checklist and scorecard completion, then sends a formatted approval request email via Google Workspace to the designated approver. If no response is recorded within 48 hours, a follow-up reminder is queued automatically. The agent continues queuing reminders until a decision is recorded in Jira, at which point it closes the approval loop.

Trigger
Jira ticket status transitions to 'Evaluation In Progress' (Jira webhook on issue_updated event, status field change)
Tools
Notion, Google Workspace, Jira
Replaces steps
Steps 4, 5, 6, and 7
Estimated build
12 hours / Moderate complexity
// Input
jira.ticket_id             : string
jira.tool_name             : string
jira.requestor_name        : string
jira.requestor_email       : string
jira.use_case              : string
jira.user_count            : integer
jira.budget_range          : string
jira.integrations_needed   : string[]

// Output (on scorecard + checklist creation)
notion.security_checklist_page_id  : string
notion.scorecard_page_id           : string
notion.checklist_status            : string   // 'Pending' | 'Complete'
notion.scorecard_status            : string   // 'Pending' | 'Complete'

// Output (on approval request sent)
gmail.approval_email_message_id    : string
gmail.reminder_scheduled_at        : ISO8601 timestamp
jira.ticket_status                 : string   // 'Pending Approval'

// On approval
jira.approval_decision             : string   // 'Approved' | 'Rejected'
jira.decision_recorded_at          : ISO8601 timestamp
jira.approver_name                 : string
jira.ticket_status                 : string   // 'Approved' | 'Rejected'
  • Notion templates: the security checklist and evaluation scorecard must be created as Notion template pages before build begins. The agent duplicates these templates into the relevant evaluation database and populates properties from the Jira ticket fields. Template page IDs must be stored as environment variables (NOTION_SECURITY_CHECKLIST_TEMPLATE_ID, NOTION_SCORECARD_TEMPLATE_ID).
  • Approval email: sent via the Gmail API (users.messages.send) using a service account with domain-wide delegation, or via an authenticated IT Manager OAuth2 token. The email must include the Notion scorecard URL, tool name, requestor name, and a clear approval/rejection reply instruction or a linked form.
  • Reminder logic: implement a scheduled polling job (every 24 hours) that checks whether the Jira ticket status is still 'Pending Approval'. If true and 48 hours have elapsed since gmail.approval_email_message_id was recorded, send a reminder. Cap reminders at three before escalating to a Slack alert in #it-alerts.
  • Approval capture: the approval decision must be recorded back into Jira via the REST API by updating the ticket status and adding a comment with approver_name and decision_recorded_at. The approval response mechanism (email reply parsing, linked form, or manual Jira update) must be confirmed with the IT Manager before build.
  • The security checklist criteria must be reviewed by a stakeholder familiar with the business's compliance obligations before the template is finalised, particularly for regulated or high-risk tool categories. This is a pre-build dependency and cannot be resolved by FullSpec unilaterally.
  • Google Workspace tier: the Gmail API requires a Google Workspace account with API access enabled. OAuth2 scopes required: gmail.send, gmail.readonly (for reply monitoring if used). Confirm API access and service account configuration during stack audit.
Procurement and Rollout Agent

Triggered when the Jira ticket status transitions to 'Approved', this agent sends a DocuSign envelope containing the vendor agreement or internal purchase order to the required signatories. Once the envelope is completed, the agent updates the Notion software register with the new tool entry including licence count, renewal date, owner, and monthly cost. It then sends a Slack notification to the requestor and any named users confirming the tool is live and linking to onboarding materials. If the approval decision is 'Rejected', the agent records the outcome in Jira and notifies the requestor via Slack without triggering DocuSign.

Trigger
Jira ticket status transitions to 'Approved' or 'Rejected' (Jira webhook on issue_updated event, status field change)
Tools
DocuSign, Notion, Slack
Replaces steps
Steps 8, 10, and 11
Estimated build
8 hours / Moderate complexity
// Input
jira.ticket_id             : string
jira.approval_decision     : string   // 'Approved' | 'Rejected'
jira.tool_name             : string
jira.requestor_name        : string
jira.requestor_email       : string
jira.user_count            : integer
jira.budget_range          : string
jira.approver_name         : string
jira.decision_recorded_at  : ISO8601 timestamp

// On approval: DocuSign output
docusign.envelope_id       : string
docusign.envelope_status   : string   // 'sent' | 'completed' | 'declined'
docusign.signed_at         : ISO8601 timestamp

// On signature completed: Notion output
notion.register_page_id    : string   // new entry in Software Register
notion.tool_name           : string
notion.licence_count       : integer
notion.renewal_date        : date
notion.owner               : string
notion.monthly_cost_usd    : number
notion.status              : string   // 'Active'

// Output: Slack notification
slack.rollout_message_ts   : string
slack.channel_or_user      : string
  • DocuSign: the vendor agreement template must be pre-loaded in DocuSign and the correct signatory roles mapped (e.g. 'Vendor Signer', 'IT Manager', 'Finance Controller') before this agent can be built. The template ID must be stored as an environment variable (DOCUSIGN_TEMPLATE_ID). A one-off setup step per agreement type is required. This is a confirmed pre-build dependency.
  • DocuSign tier: DocuSign Personal or Standard plan is sufficient for this volume. The eSignature REST API v2.1 is used. Authentication via JWT grant (recommended for server-to-server) or Authorization Code grant. Account ID and integration key must be provisioned and stored securely.
  • If the approval decision is 'Rejected', skip all DocuSign logic. Update the Jira ticket status to 'Rejected', add a comment with the approver name and timestamp, and send a Slack direct message to the requestor notifying them of the outcome. Do not post rejection details publicly in a shared channel.
  • Notion register update: triggered by the DocuSign 'envelope completed' webhook event, not on envelope send. The agent must listen for the docusign.envelope_status = 'completed' event before writing to Notion. Map licence_count, renewal_date, owner, and monthly_cost_usd from the Jira ticket fields or prompt IT to populate these on the ticket before the workflow proceeds.
  • Slack rollout notification: resolve the requestor's Slack user ID via users.lookupByEmail. If the Jira ticket contains additional named users (a multi-user field), resolve each and send individual DMs or a single message in a relevant channel. Include the tool name, a confirmation that access is being provisioned, and a link to the onboarding materials page in Notion.
  • Fallback on DocuSign decline: if docusign.envelope_status = 'declined', update the Jira ticket to 'Procurement Stalled', alert the IT Manager via Slack DM, and halt the workflow. Do not auto-retry without human review.
Developer Handover PackPage 2 of 4
FS-DOC-04Technical

03End-to-end data flow

Full trigger-to-output data flow across all three agents and tool integrations
// ============================================================
// TRIGGER
// ============================================================
// Event: Google Workspace intake form submitted
// Webhook payload received by orchestration layer

TRIGGER {
  form.requestor_name        = 'string'
  form.requestor_email       = 'string'
  form.tool_name             = 'string'
  form.use_case              = 'string'
  form.user_count            = integer
  form.budget_range          = 'string'
  form.integrations_needed   = ['string', ...]
  form.submitted_at          = ISO8601
}

// ============================================================
// AGENT 1: Request Intake Agent
// ============================================================

// Step 1a: Create Jira ticket
POST /rest/api/3/issue {
  project.key   -> env: JIRA_PROJECT_KEY
  issuetype     -> 'Task' or 'Tool Request'
  summary       -> form.tool_name + ' - Tool Request'
  description   -> form.use_case
  customfield_requestor_name   -> form.requestor_name
  customfield_requestor_email  -> form.requestor_email
  customfield_user_count       -> form.user_count
  customfield_budget_range     -> form.budget_range
  customfield_integrations     -> form.integrations_needed
  status        -> 'Intake Received'
}
RETURNS: jira.ticket_id  // e.g. 'IT-204'

// Step 1b: Query Notion software register for duplicate
POST /v1/databases/{NOTION_SOFTWARE_REGISTER_DB_ID}/query {
  filter: { property: 'Tool Name', rich_text: { contains: form.tool_name } }
}
IF results.length > 0:
  jira.duplicate_flag      = true
  jira.duplicate_tool_name = results[0].properties['Tool Name'].title
  // Update Jira ticket with duplicate flag; halt agent handoff
  // IT Manager reviews and closes ticket manually
ELSE:
  jira.duplicate_flag = false
  // Proceed to agent handoff

// Step 1c: Acknowledge requestor via Slack
GET /api/users.lookupByEmail?email={form.requestor_email}
  -> slack.user_id  (fallback: post to #it-requests if not found)
POST /api/chat.postMessage {
  channel -> slack.user_id
  text    -> 'Your request for {form.tool_name} has been received. Ticket: {jira.ticket_id}'
}
RETURNS: slack.ack_message_ts

// ============================================================
// AGENT 1 -> AGENT 2 HANDOFF
// Condition: jira.duplicate_flag = false
// Trigger: Jira ticket status updated to 'Evaluation In Progress'
// ============================================================

// ============================================================
// AGENT 2: Evaluation and Approval Agent
// ============================================================

// Step 2a: Duplicate Notion security checklist template
POST /v1/pages {
  parent.database_id -> env: NOTION_SECURITY_CHECKLIST_DB_ID
  properties: {
    'Tool Name'    -> jira.tool_name
    'Ticket ID'    -> jira.ticket_id
    'Status'       -> 'Pending'
    'Assigned To'  -> 'IT Manager'
  }
  // Content cloned from NOTION_SECURITY_CHECKLIST_TEMPLATE_ID
}
RETURNS: notion.security_checklist_page_id

// Step 2b: Duplicate Notion scorecard template
POST /v1/pages {
  parent.database_id -> env: NOTION_SCORECARD_DB_ID
  properties: {
    'Tool Name'        -> jira.tool_name
    'Ticket ID'        -> jira.ticket_id
    'Use Case'         -> jira.use_case
    'User Count'       -> jira.user_count
    'Budget Range'     -> jira.budget_range
    'Integrations'     -> jira.integrations_needed
    'Scorecard Status' -> 'Pending'
  }
}
RETURNS: notion.scorecard_page_id

// Step 2c: Poll Notion for checklist and scorecard completion
// Scheduled check every 6 hours
GET /v1/pages/{notion.security_checklist_page_id}
  -> notion.checklist_status  // watch for 'Complete'
GET /v1/pages/{notion.scorecard_page_id}
  -> notion.scorecard_status  // watch for 'Complete'

// Step 2d: Send approval request email once both statuses = 'Complete'
POST /gmail/v1/users/me/messages/send {
  to      -> approver_email  // resolved from APPROVER_EMAIL env var
  subject -> 'Approval required: {jira.tool_name} evaluation'
  body    -> evaluation summary + notion.scorecard_page_id URL
}
RETURNS: gmail.approval_email_message_id
SET: gmail.reminder_scheduled_at = now() + 48h
UPDATE: jira.ticket_status -> 'Pending Approval'

// Step 2e: Reminder logic (scheduled poller every 24h)
IF jira.ticket_status = 'Pending Approval'
   AND now() > gmail.reminder_scheduled_at:
  // Send reminder email (up to 3 times)
  // On 3rd miss: POST Slack alert to #it-alerts

// Step 2f: Capture approval decision
// Via Jira ticket status update (manual by approver or form response)
ON jira.ticket_status IN ('Approved', 'Rejected'):
  jira.approval_decision    = ticket.status
  jira.decision_recorded_at = now()
  jira.approver_name        = ticket.updated_by.displayName

// ============================================================
// AGENT 2 -> AGENT 3 HANDOFF
// Trigger: Jira ticket status transitions to 'Approved' or 'Rejected'
// ============================================================

// ============================================================
// AGENT 3: Procurement and Rollout Agent
// ============================================================

// Branch A: Approval decision = 'Rejected'
IF jira.approval_decision = 'Rejected':
  UPDATE jira.ticket_status -> 'Rejected'
  POST /api/chat.postMessage to requestor slack.user_id
    text -> 'Your request for {jira.tool_name} was not approved.'
  HALT

// Branch B: Approval decision = 'Approved'
// Step 3a: Send DocuSign envelope
POST /v2.1/accounts/{DOCUSIGN_ACCOUNT_ID}/envelopes {
  templateId        -> env: DOCUSIGN_TEMPLATE_ID
  templateRoles: [
    { roleName: 'IT Manager',       email: IT_MANAGER_EMAIL, name: IT_MANAGER_NAME }
    { roleName: 'Finance Controller', email: FINANCE_EMAIL,  name: FINANCE_NAME }
  ]
  status: 'sent'
}
RETURNS: docusign.envelope_id

// Step 3b: Listen for DocuSign envelope webhook event
ON docusign.envelope_status = 'completed':
  docusign.signed_at = envelope.completedDateTime

  // Step 3c: Update Notion software register
  POST /v1/pages {
    parent.database_id -> env: NOTION_SOFTWARE_REGISTER_DB_ID
    properties: {
      'Tool Name'      -> jira.tool_name
      'Status'         -> 'Active'
      'Licence Count'  -> jira.user_count
      'Owner'          -> jira.requestor_name
      'Monthly Cost'   -> parsed from jira.budget_range
      'Renewal Date'   -> signed_at + 12 months
      'Ticket ID'      -> jira.ticket_id
    }
  }
  RETURNS: notion.register_page_id

  // Step 3d: Send Slack rollout notification
  POST /api/chat.postMessage {
    channel -> slack.user_id (requestor)
    text    -> '{jira.tool_name} is approved and being provisioned.
                Onboarding materials: {notion.scorecard_page_id URL}'
  }
  RETURNS: slack.rollout_message_ts

ON docusign.envelope_status = 'declined':
  UPDATE jira.ticket_status -> 'Procurement Stalled'
  POST Slack alert to IT Manager DM
  HALT

// ============================================================
// END OF FLOW
// ============================================================
Developer Handover PackPage 3 of 4
FS-DOC-04Technical

04Recommended build stack

Orchestration layer
A workflow automation platform with support for webhook triggers, scheduled polling, multi-step branching, and credential management. One workflow per agent (three workflows total). All credentials stored in a shared credential store within the platform, not hardcoded in workflow nodes. Environment variables used for all IDs and keys (see list below).
Environment variables required
JIRA_PROJECT_KEY, JIRA_API_BASE_URL, JIRA_USER_EMAIL, JIRA_API_TOKEN, NOTION_SOFTWARE_REGISTER_DB_ID, NOTION_SECURITY_CHECKLIST_DB_ID, NOTION_SCORECARD_DB_ID, NOTION_SECURITY_CHECKLIST_TEMPLATE_ID, NOTION_SCORECARD_TEMPLATE_ID, GMAIL_SERVICE_ACCOUNT_JSON (or GMAIL_OAUTH_TOKEN), APPROVER_EMAIL, IT_MANAGER_EMAIL, IT_MANAGER_NAME, FINANCE_EMAIL, FINANCE_NAME, DOCUSIGN_ACCOUNT_ID, DOCUSIGN_TEMPLATE_ID, DOCUSIGN_JWT_PRIVATE_KEY, SLACK_BOT_TOKEN, SLACK_IT_ALERTS_CHANNEL_ID
Webhook configuration
Inbound webhooks: (1) Google Workspace form submission webhook to Agent 1 workflow endpoint. (2) Jira issue_updated webhook filtered on status field changes to 'Evaluation In Progress', 'Approved', and 'Rejected', routed to Agent 2 and Agent 3 respectively. (3) DocuSign Connect webhook on envelope status events ('completed', 'declined') routed to Agent 3. All inbound webhooks must be secured with a shared secret or HMAC signature verified at the orchestration layer entry point.
Templating approach
Notion page creation uses server-side property mapping from Jira ticket fields. Email body for approval requests uses a stored template string with field interpolation (tool_name, requestor_name, scorecard URL, ticket ID). Slack messages use plain text with field interpolation. No client-side rendering. All templates versioned in the workflow platform and documented in the Integration and API Spec (Doc 5).
Error logging
All workflow execution errors written to a dedicated Supabase table (schema: workflow_errors: id, agent_name, step_name, error_message, payload_snapshot, occurred_at, resolved). On write, a Slack alert is posted to #it-alerts with the agent name, step, and error summary. Errors do not silently swallow: any uncaught exception halts the relevant branch and logs before halting. Supabase project and table must be provisioned before build begins.
Testing approach
All agents are built and tested against sandbox or staging instances first. Jira sandbox project ('IT-TEST'), Notion duplicate test database, DocuSign sandbox account, and a dedicated Slack test channel (#it-automation-test) are required. No production data or production DocuSign envelopes during QA. Promote to production only after all test cases in the Test and QA Plan (Doc 6) pass. End-to-end test runs use sample tool request submissions with known expected outcomes.
Estimated total build time
Request Intake Agent: 8 hours. Evaluation and Approval Agent: 12 hours. Procurement and Rollout Agent: 8 hours. End-to-end integration testing and QA: 8 hours (estimated from template build_effort_hours of 28 hours total, per snapshot). Grand total: 36 hours across the 4-week delivery window.
Pre-build blockers that must be resolved before any agent can be built: (1) The Notion software register must be cleaned and standardised. Incomplete or inconsistently formatted entries will cause false negatives in the duplicate check. (2) The DocuSign vendor agreement template must be pre-loaded and signatory roles mapped. (3) The security checklist criteria must be reviewed and approved by a stakeholder familiar with the business's compliance obligations. (4) Approval roles (who receives the approval email and who is authorised to approve) must be confirmed and documented. FullSpec cannot proceed past the Discovery and Stack Audit stage until these four items are confirmed. Contact support@gofullspec.com to flag any blockers.
Item
Owner
Status
Notion software register cleaned and standardised
[Your team]
Confirm before build
Jira project key and issue type confirmed
[Your team]
Confirm before build
DocuSign template pre-loaded and signatory roles mapped
[Your team]
Confirm before build
Security checklist criteria reviewed for compliance obligations
[Your team]
Confirm before build
Approval roles and approver email addresses confirmed
[Your team]
Confirm before build
Google Workspace API access and OAuth2 scopes provisioned
FullSpec
In progress
Supabase error logging table provisioned
FullSpec
In progress
DocuSign sandbox account configured for QA
FullSpec
In progress
All three agent workflows built and unit tested
FullSpec
Upcoming
End-to-end QA pass against Test and QA Plan (Doc 6)
FullSpec
Upcoming
Developer Handover PackPage 4 of 4

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
Integration and API Spec
Technical · Developer
View
Test and QA Plan
Quality · Developer
View