Managing Change Requests with Notion, Zapier, and Slack

The Business Situation

Alder Vale Instruments is a fictional 86-person manufacturer of industrial measurement and test equipment. Product Management and R&D employ ten people, IT and infrastructure employ four, and operations and manufacturing account for approximately 38 employees. Quality, finance, and department leaders participate in reviews when a proposed change affects their responsibilities.

The company processes approximately 28 product, system, and manufacturing-process change requests each month. Requests range from firmware updates and test-station configuration changes to workflow revisions, infrastructure maintenance, supplier substitutions, and production-line adjustments.

Employees already use Google Workspace for forms, spreadsheets, and files, Notion for product documentation, Slack for internal communication, and email for formal correspondence. However, there is no consistent change-control workflow connecting those systems.

Requests arrive through Slack messages, email, meetings, and spreadsheet rows. Some contain a clear business reason and test plan. Others contain only a short description. Reviewers cannot consistently determine who is affected, what the risks are, whether testing was completed, who approved the work, or how the previous state would be restored if implementation failed.

The primary operational owner is the product operations manager, acting as change coordinator. Technical ownership varies by request. An R&D lead owns product changes, the IT service lead owns infrastructure changes, and a manufacturing engineering manager owns production-process changes. Business owners, quality representatives, and department directors provide approvals according to risk and impact.

Note: This case study is provided as a representative example of the types of AI integration and digital transformation solutions Intelligex designs and delivers. Actual engagements are tailored to each client’s goals, constraints, existing systems, timeline, and available resources, so the approach, tools, and outcomes may vary.

The Existing Process

The original process followed an informal sequence:

1. An employee described a requested change in Slack, email, a meeting, or a spreadsheet.
2. A department manager decided whether the request appeared worth investigating.
3. The requester or a technical employee collected additional information through messages and meetings.
4. Testing was arranged when someone considered it necessary. Test evidence might be stored in Google Drive, attached to an email, or described in Slack.
5. Approval was requested from one or more managers. The required approvers varied because there was no documented approval matrix.
6. An employee implemented the change and announced completion in Slack.
7. If the result was unsatisfactory, the team attempted to reconstruct the previous configuration from available files, messages, or employee knowledge.
8. The original spreadsheet was sometimes updated, but closure notes and evidence were inconsistent.

Duplicate data entry also occurred. A request might begin in Slack, be copied into a spreadsheet, appear in a Notion project page, and then be summarized again in an approval email. Status changes did not consistently propagate between those locations.

The absence of an event history created an audit problem. A completed record might show its final status, but not when it entered testing, who returned it for more information, which approver accepted a condition, or whether the rollback plan existed before implementation.

The company needed to change the process because volume was increasing, production systems were becoming more connected, and changes increasingly crossed departmental boundaries. A lightweight but controlled workflow was required before the administrative burden and operational risk became harder to manage.

What the New System Needed to Do

The team documented the business and technical requirements before selecting an automation design.

Implementation Approaches Considered

Standardized Manual Process

A better template and a single spreadsheet would improve consistency, but employees would still need to copy information, chase reviewers, create folders, update statuses, and compile reports. The approach did not sufficiently address audit history or disconnected evidence.

Google Workspace Automation

Google Apps Script could create identifiers, write records, create Drive folders, and call Slack webhooks. This was technically viable. It was not selected because the team wanted Notion to remain the operational workspace and did not want every workflow change to require JavaScript maintenance.

Notion with Zapier

This approach retained tools employees already understood. Notion could represent requests, tests, events, and relationships. Zapier could connect form submissions, Notion records, Drive folders, and Slack notifications. It offered sufficient control for 28 monthly requests without requiring a custom user interface.

Dedicated Software

A dedicated IT service management, product lifecycle management, or quality-management platform could provide stronger native controls. It was considered disproportionate for the representative volume and current workflow maturity. The company first needed stable requirements and consistent adoption.

Custom Application

A custom application could enforce every transition and permission at the database level. The implementation effort, testing burden, hosting responsibility, and ongoing support requirements were not justified for this use case.

The Selected Solution

The selected implementation uses Google Forms for intake and approval responses, Google Sheets as the form-response staging ledger, Notion as the operational system of record, Zapier as the automation layer, Google Drive for controlled evidence storage, and Slack for notifications.

Notion remains the authoritative operational record. Google Sheets is not used as a second status database. Its automation columns indicate whether each form response was accepted, rejected, or linked to a Notion page.

Manual copying, folder creation, initial routing, routine status notifications, approval reminders, and event-log creation are removed. Impact ratings, test acceptance, final approval, implementation authorization, rollback decisions, and closure remain human-controlled.

System Architecture and Data Flow

1. Submission: An employee submits the restricted Google change-request form. Google Forms validates required answers and writes the response to its linked Google Sheet.
2. Trigger: Zapier detects the new response row. The trigger supplies the timestamp, responder email, answers, and source row identifier.
3. Normalization: A Code by Zapier step trims text, validates allowed values, checks dates and evidence links, creates a deterministic source key, and generates a change ID.
4. Duplicate check: Zapier queries the Notion Change Requests database for the source key or change ID. An existing result stops record creation and links the source row to the existing page.
5. Record and folder creation: Zapier creates a restricted Drive folder, creates the Notion change record, and writes the returned folder URL and Notion page identifier to the appropriate systems.
6. Initial history: Zapier creates a related Change Event recording submission, source, actor, timestamp, and initial status.
7. Notification: Zapier posts a concise message to the private Slack change-review channel. The message contains the change ID, title, risk signals, owner, and Notion link, but not sensitive supporting detail.
8. Review and testing: Employees complete impact analysis in Notion, add related test-run records, and store evidence in the change folder. Valid status transitions create event records and notifications.
9. Approval: Required reviewers submit a restricted approval form. Zapier verifies the reviewer, records the decision as an immutable event, updates the change record, and notifies the coordinator.
10. Implementation and monitoring: The implementation owner updates evidence and status. Delayed Zapier runs confirm that the record is still awaiting action before sending reminders or escalations.
11. Closure or rollback: The coordinator closes the request after monitoring evidence is complete, or records a rollback with its trigger, outcome, and evidence.
12. Failure path: Invalid submissions, unauthorized decisions, invalid transitions, and incomplete automation runs are marked for manual review. Raw form data remains available for recovery.

• Intake: Google Forms with responses stored in Google Sheets
• System of record: Related Notion databases
• Automation layer: Zapier, including filters, paths, delays, formatter actions, and JavaScript code steps
• Document storage: Google Drive shared-drive folders
• Notifications: Private Slack channels and direct messages where appropriate
• Reporting: Notion operational views, event history, and Google Sheets reconciliation
• AI layer: Optional structured impact-analysis assistant with human review

Data Structure

The design uses four related Notion databases: Change Requests, Change Events, Test Runs, and Routing Rules. A Change Request can have many Change Events and many Test Runs. Routing Rules provide active owner and approver information for a change area.

Notion does not enforce database uniqueness in the same way as a relational database. The implementation therefore combines deterministic identifiers, a pre-create search, source-ledger status, and event source keys. These controls provide practical idempotency at the representative volume.

Two useful calculated properties are Age in Days and Overdue. The exact Notion formula syntax can vary with formula-version changes, so the formulas should be tested in the current workspace.

Age in Days:
if(empty(prop("Submitted At")), 0, dateBetween(now(), prop("Submitted At"), "days"))

Overdue:
and(
  not empty(prop("Due Date")),
  prop("Due Date") < now(),
  prop("Status") != "Closed",
  prop("Status") != "Rejected"
)

Workflow Statuses and Ownership

Sending a request backward is allowed when the reason is documented. Failed testing returns the request to Planned or Needs Information. A reviewer can return an approval for more information, which moves the record to Needs Information. Rejection closes the current proposal but does not prevent a substantially revised request from being submitted later.

Rollback is not treated as an automation failure. It is a controlled operational outcome with its own evidence, ownership, and follow-up.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

1. Create or identify a Google Workspace account owned by the organization for the change forms. Avoid using a personal employee account as the sole owner.
2. Create a shared drive or controlled shared folder named Change Control Evidence. Grant contributor access to implementation and test owners, and manager access only to the small group responsible for permissions and retention.
3. Create a Notion teamspace for Change Control. Restrict the Change Requests, Change Events, Test Runs, and Routing Rules databases to participating departments.
4. Connect Notion to Zapier using a dedicated automation owner. Share only the required databases with the Notion integration. Notion integration access depends on the pages explicitly shared with it. The official Notion authorization documentation explains the underlying access model.
5. Connect Google Sheets and Google Drive to Zapier using an organizational automation account with access only to the form-response files and evidence parent folder.
6. Connect Slack to Zapier using an approved application connection. Invite the app to the private change-review and automation-alert channels if required by workspace settings.
7. Confirm that the Zapier subscription supports the required multi-step automations, paths or filters, delayed actions, code steps, and expected monthly task volume. Feature availability and labels may vary by subscription and product version.
8. Create a test Notion teamspace, test forms, test spreadsheets, test Drive parent folder, and private Slack test channel. Do not build the first version against production records.
9. Create test identities for a requester, technical owner, business approver, operations approver, IT approver, and coordinator. Each test user should have only the access expected for the role.
10. Document the primary automation owner and a backup owner. Store recovery instructions in an administrator-only Notion page.

Use placeholders such as YOUR_AUTOMATION_OWNER_EMAIL, YOUR_NOTION_DATABASE_ID, YOUR_DRIVE_PARENT_FOLDER_ID, and YOUR_SLACK_CHANNEL_ID during configuration. Do not place passwords or API keys inside Notion properties, form descriptions, Slack messages, or JavaScript source.

Step 2: Build the Intake

Create two Google Forms: Change Request Intake and Change Review Decision. Restrict both to authorized organizational users where the Workspace configuration permits it. Enable collection of verified responder email addresses.

Use form sections to display the Emergency Reason question when Emergency is selected. Interface labels may vary, but the underlying behavior is branching to a required section based on a multiple-choice answer.

Do not enable open file uploads unless the organization has confirmed identity, storage, malware-scanning, and access requirements. This implementation initially accepts HTTPS evidence links and creates a controlled Drive folder after validation.

Add a privacy notice stating that operational information will be stored in Google Workspace and Notion, processed by Zapier, and referenced in restricted Slack notifications. Tell requesters not to submit credentials, authentication tokens, unnecessary personal data, export-controlled material, or confidential customer content.

The confirmation message should explain that submission does not authorize implementation and that the tracking ID will appear after processing.

The approval form collects the authenticated responder email. Zapier compares that email to the expected approver stored on the change record. Entering another employee’s name does not satisfy the control.

Link each form to its own Google Sheet. Add automation columns to the right of the form-response columns:

• Processing Status
• Change ID
• Source Submission Key
• Notion Page ID
• Notion Page URL
• Processed At
• Retry Count
• Error Message

Do not rename or reorder live form-response headers after mapping the Zaps. If a question must change, test the resulting spreadsheet columns and remap the automation before publishing it.

Step 3: Create the System of Record

1. Create the four Notion databases described in the Data Structure section.
2. Use CR-YYYYMMDD-HASH for change IDs, EV-CHANGEID-SOURCE for event IDs, and TEST-CHANGEID-SEQUENCE for test IDs.
3. Set new Change Requests to Submitted, Automation Status to Pending, Retry Count to 0, Test Result to Not Started, and Status Version to 1.
4. Create relations from Change Events and Test Runs to Change Requests. Add rollups on Change Requests for event count, latest event time, test count, and latest test result if useful.
5. Create a Routing Rule for each supported affected area. Use exact routing keys such as AREA:IT and AREA:MANUFACTURING.
6. Store approver email addresses and Slack member IDs in Routing Rules. Do not store passwords, tokens, or private keys.
7. Create templates for product, IT, and manufacturing changes. Each template should include headings for impact, dependencies, test plan, implementation sequence, rollback trigger, rollback steps, monitoring, and closure.
8. Add Notion created-time, last-edited-time, and last-edited-by properties to support audit attribution.
9. Create a restricted Automation Failures view filtered where Automation Status is Failed, Retry Pending, or Manual Review.
10. Lock database structure for normal contributors after testing. Contributors should edit records, not property definitions.

The event database is append-only by operating policy. Normal users receive view access, while Zapier and designated coordinators can create events. Corrections are recorded as new correction events rather than silently editing prior decisions.

Step 4: Connect the Tools

Configure each connection with the least-privileged organizational account. Test access by reading one test record, creating one test page, creating one test folder, and posting one message to the test Slack channel.

Connector action names can change. The required operations are: detect a new spreadsheet row, query a Notion database item by an exact property, create and update a Notion database item, create a Drive folder, send a Slack message, retrieve a Notion page, delay execution, and update a spreadsheet row.

Step 5: Build the Core Automation

Automation A: Intake to Change Record

• Trigger: New row in the Google Forms response sheet.
• Conditions: Processing Status is blank, required data is valid, and no Notion record has the same source key or change ID.
• Actions: Normalize data, generate identifiers, find routing rule, create Drive folder, create Notion record, create submission event, send Slack notification, and update the source row.
• Fields updated: Change ID, owners, status, folder URL, Notion page ID, automation status, processed time, Slack identifiers, and source-ledger fields.
• Notification: New-request message in the private change-review channel.
• Exception: Invalid input is marked Validation Failed. A partial run remains Pending or Retry Pending for reconciliation.

The exact action order is important:

1. Read the source row.
2. Run normalization and validation code.
3. Route invalid records to a spreadsheet update and coordinator alert.
4. Query Notion by Source Submission Key.
5. If a record exists, write its ID and URL to the source row and stop.
6. Query the active Routing Rule using the normalized affected area.
7. Create a Drive folder named with the change ID and sanitized title.
8. Create the Notion Change Request using Submitted as the status.
9. Create the initial Change Event using the source key as the event idempotency key.
10. Post the Slack notification.
11. Update the Notion record with returned Slack identifiers and Automation Status Complete.
12. Update the Google Sheets row with processing results.

Automation B: Status Transition and History

• Trigger: Updated item in the Notion Change Requests database.
• Conditions: Status differs from Last Logged Status.
• Actions: Validate the transition, create an event, increment Status Version, set reminder timing, update Last Logged Status, and notify the responsible person.
• Fields updated: Last Logged Status, Status Version, Status Entered At, Last Automation Run, Automation Status, and Error Message.
• Notification: Status-specific Slack message or alert.
• Exception: An invalid transition is restored to the last valid status and recorded as Transition Blocked.

The event must be created before Last Logged Status is updated. If event creation fails, the mismatch remains visible and the transition can be replayed. When the Zap updates Last Logged Status, the Notion update trigger may fire again, but the filter stops because the statuses now match.

Automation C: Reviewer Decision

• Trigger: New row in the approval-form response sheet.
• Conditions: Change ID exists, request is Awaiting Approval, responder email matches the expected approver for the selected role, and no decision event has the same source key.
• Actions: Create a decision event, update the corresponding approval field, change status when the decision requires it, notify the coordinator, and update the decision ledger.
• Fields updated: Role approval, approval comment, decision time, status when applicable, and automation fields.
• Notification: Decision summary to the coordinator and remaining reviewers.
• Exception: Unauthorized or stale decisions enter Manual Review and do not alter approval fields.

Reject changes the record to Rejected after the event is created. Return for More Information changes the status to Needs Information. Approve updates the applicable role field. The final coordinator reviews the complete approval set and submits the final decision. The system does not infer final approval merely because several individual fields contain Approve.

Automation D: Implementation and Closure Events

• Trigger: Valid status movement to Implementing, Monitoring, Rolled Back, or Closed.
• Conditions: Required evidence and ownership fields are present.
• Actions: Create the status event, update timestamps, send the appropriate Slack notice, and preserve implementation or rollback evidence links.
• Fields updated: Implementation Started At, Implemented At, Monitoring Started At, Rolled Back At, Closed At, and outcome fields.
• Notification: Implementation start, rollback alert, monitoring start, or closure message.
• Exception: Missing evidence blocks the transition and returns the record to the last valid state.

Step 6: Add Approvals, Reminders, and Escalations

Approval requirements are determined during impact review. The following representative rules are configured:

• Every request requires a business-owner decision and final coordinator approval.
• IT systems, security, personal data, authentication, networks, or integrations require an IT reviewer.
• Manufacturing, quality, supplier, safety, or regulatory impacts require an operations or quality reviewer.
• High-risk requests, cost of 10,000 or more, or expected downtime above 30 minutes require all applicable department approvals before the final coordinator decision.
• Emergency priority shortens timing but does not eliminate testing, rollback planning, event logging, or retrospective approval evidence.

Approvals can occur in parallel after the request enters Awaiting Approval. The final coordinator decision is sequential and occurs only after all applicable role decisions are present.

When a request enters a reminder-controlled status, the status-history Zap starts a delayed branch:

1. Capture the Change ID, Notion page ID, status, and Status Version.
2. Delay for the configured reminder period.
3. Retrieve the current Notion record.
4. Continue only if the current status and Status Version match the captured values.
5. Send the first reminder to the owner or outstanding approver.
6. Delay until the escalation interval.
7. Retrieve the record again and repeat the version check.
8. Send an escalation to the coordinator or department lead.
9. Create reminder and escalation events if those messages are material to the audit record.

The Status Version check prevents an old delayed run from reminding an employee about a stage the request has already left.

If an approver is unavailable, the coordinator updates the expected approver to an authorized delegate before the delegate submits a decision. The change creates an Approver Reassigned event containing the reason, previous approver, new approver, actor, and time.

Approval evidence consists of the authenticated form-response email, source timestamp, form-row identifier, decision, comment, role, related Notion event, and current expected approver. Slack reactions are not accepted as approval evidence.

Step 7: Add Documents and File Management

Create the following shared-drive structure:

Change Control Evidence
  Active
    2026
      CR-20260715-7A31C2 Calibration Threshold Update
  Closed
    2026
  Rolled Back
    2026
  Templates
  Quarantine

Zapier creates each active change folder under the appropriate year. Use the change ID first so searches and exports remain reliable if the title changes.

Recommended file names are:

• CR-ID_TestPlan_v01_YYYYMMDD
• CR-ID_TestEvidence_Environment_YYYYMMDD
• CR-ID_ImplementationPlan_v01_YYYYMMDD
• CR-ID_RollbackPackage_v01_YYYYMMDD
• CR-ID_MonitoringEvidence_YYYYMMDD
• CR-ID_ClosureSummary_YYYYMMDD

Use native Google Drive version history for files that support it. Do not replace evidence silently. If a file must be superseded, retain the prior version or record the replacement in a Change Event.

Folder permissions inherit from the restricted parent. Sensitive changes can use a more restricted subfolder with a link in the Notion record. Shared links should be limited to named organizational users rather than anyone with the link.

If folder creation fails, the Notion record remains Automation Status Retry Pending and does not move beyond Submitted. Staff can create the folder manually using the same naming convention, paste its URL into Notion, record a Manual Recovery event, and resume the workflow.

Large files should remain in Drive rather than being copied through every Zap step. Zapier transports URLs and identifiers, reducing task payloads and timeout risk.

Step 8: Add Reporting and Operational Views

For processing-time reporting, calculate durations between event timestamps rather than relying only on the current record. Useful measures include submission-to-triage time, impact-review duration, testing duration, approval duration, scheduled-to-implemented variance, and monitoring duration.

The Google Sheets reconciliation view compares all intake rows with Notion Page ID and Processing Status. A blank page ID more than 15 minutes after submission is an alert condition during business hours.

Dashboard ownership belongs to the product operations manager. The automation owner maintains technical views, while department leads review workload and aging weekly.

Step 9: Add Security and Governance Controls

• Restrict both Google Forms to authorized organizational users when possible.
• Use verified responder email instead of a self-entered approver name.
• Give the Notion integration access only to the change-control databases.
• Restrict Change Events editing to the integration and designated coordinators.
• Limit Slack notifications to operational metadata and links. Keep detailed security, personal-data, and quality evidence in restricted Notion pages or Drive folders.
• Use organization-owned Google files and automation connections.
• Store credentials in managed application connections or an approved secret manager, not in code or record properties.
• Review former-employee access promptly across Google Workspace, Notion, Zapier, and Slack.
• Retain closed records according to the organization’s approved retention schedule. The representative design uses 36 months for ordinary operational records, while regulated, contractual, quality, safety, or legal-hold records follow the applicable policy.
• Export or back up essential change metadata and event history on a defined schedule. Confirm that backups can be restored, not merely created.
• Require human approval for high-risk, safety, security, privacy, production, financial, and regulatory decisions.
• Prohibit credentials, secrets, raw personal records, and unnecessarily sensitive content from optional AI processing.

Notion page history, Google Forms timestamps, Google Sheets source rows, Zapier run history, Slack message metadata, Drive activity, and Change Events provide complementary evidence. None should be treated as the sole audit source.

Step 10: Deploy and Test

1. Build the forms, databases, Zaps, folders, and channels in the test environment.
2. Create at least 20 sample requests covering every change type, risk level, approval route, and terminal outcome.
3. Test with separate requester, owner, approver, and coordinator accounts.
4. Run technical tests for validation, duplicate events, stale reminders, failed actions, unauthorized approvals, rollback, and recovery.
5. Conduct user acceptance testing with one R&D employee, one IT employee, one manufacturing employee, one quality reviewer, and the change coordinator.
6. Correct field labels, routing rules, notification content, and permission problems found during testing.
7. Freeze structural changes, duplicate the tested configuration where necessary, and replace test IDs with production IDs.
8. Pilot the production workflow with one department for two weeks while the old spreadsheet remains read-only as a fallback reference.
9. Activate the remaining departments after pilot records complete successfully.
10. Publish a one-page requester guide, reviewer guide, owner guide, and recovery runbook.
11. Announce the effective date and state that Slack messages and emails no longer constitute authorized change requests or approvals.
12. Monitor every automation run during the first week and review exceptions daily for the first month.

A rollback of the workflow itself consists of pausing the Zaps, keeping the forms closed or clearly marked, exporting active Notion records, and using a controlled temporary spreadsheet. Records already created should not be deleted merely because the automation is paused.

Code and Configuration

The implementation uses native Zapier actions for application connections, but two JavaScript code steps provide stable validation and transition control. The code runs inside Code by Zapier and does not require external packages.

Intake Normalization and Identifier Code

Place the following code in the JavaScript code action immediately after the new-row trigger. Map the trigger values to the listed inputData keys. The source row identifier may have a different label depending on the Google Sheets connector version.

/*
Required inputData keys:
submitted_at
requester_email
request_title
change_type
affected_area
business_reason
current_state
proposed_change
affected_users
risk_signals
initial_risk
cost_band
requested_priority
desired_date
success_criteria
test_idea
rollback_possible
rollback_approach
evidence_links
emergency_reason
attestation
spreadsheet_id
row_number
*/

function clean(value, maxLength) {
  const text = String(value || "").trim().replace(/\s+/g, " ");
  return text.slice(0, maxLength);
}

function stableHash(value) {
  let hash = 0x811c9dc5;
  for (let i = 0; i < value.length; i += 1) {
    hash ^= value.charCodeAt(i);
    hash = Math.imul(hash, 0x01000193);
  }
  return (hash >>> 0).toString(16).padStart(8, "0").toUpperCase();
}

function isAllowed(value, allowedValues) {
  return allowedValues.includes(value);
}

function validHttpsUrls(value) {
  if (!value) {
    return { valid: true, normalized: "" };
  }

  const urls = String(value)
    .split(/\r?\n/)
    .map((item) => item.trim())
    .filter(Boolean);

  const invalid = urls.filter((url) => !/^https:\/\//i.test(url));
  return {
    valid: invalid.length === 0,
    normalized: urls.join("\n")
  };
}

try {
  const errors = [];

  const submittedAtRaw = clean(inputData.submitted_at, 100);
  const requesterEmail = clean(inputData.requester_email, 254).toLowerCase();
  const requestTitle = clean(inputData.request_title, 120);
  const changeType = clean(inputData.change_type, 50);
  const affectedArea = clean(inputData.affected_area, 50);
  const businessReason = clean(inputData.business_reason, 5000);
  const currentState = clean(inputData.current_state, 5000);
  const proposedChange = clean(inputData.proposed_change, 5000);
  const affectedUsersRaw = clean(inputData.affected_users, 20);
  const riskSignals = clean(inputData.risk_signals, 500);
  const initialRisk = clean(inputData.initial_risk, 30);
  const costBand = clean(inputData.cost_band, 50);
  const requestedPriority = clean(inputData.requested_priority, 30);
  const desiredDateRaw = clean(inputData.desired_date, 50);
  const successCriteria = clean(inputData.success_criteria, 5000);
  const testIdea = clean(inputData.test_idea, 5000);
  const rollbackPossible = clean(inputData.rollback_possible, 20);
  const rollbackApproach = clean(inputData.rollback_approach, 5000);
  const emergencyReason = clean(inputData.emergency_reason, 5000);
  const attestation = clean(inputData.attestation, 200);
  const spreadsheetId = clean(inputData.spreadsheet_id, 200);
  const rowNumber = clean(inputData.row_number, 30);

  const submittedAt = new Date(submittedAtRaw);
  if (Number.isNaN(submittedAt.getTime())) {
    errors.push("Submission timestamp is invalid.");
  }

  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(requesterEmail)) {
    errors.push("Requester email is invalid.");
  }

  if (requestTitle.length < 10) {
    errors.push("Request title must contain at least 10 characters.");
  }

  if (businessReason.length < 30) {
    errors.push("Business reason must contain at least 30 characters.");
  }

  if (currentState.length < 20) {
    errors.push("Current state must contain at least 20 characters.");
  }

  if (proposedChange.length < 30) {
    errors.push("Proposed change must contain at least 30 characters.");
  }

  if (successCriteria.length < 20) {
    errors.push("Success criteria must contain at least 20 characters.");
  }

  if (testIdea.length < 20) {
    errors.push("Initial test idea must contain at least 20 characters.");
  }

  const allowedTypes = [
    "Product",
    "System",
    "Manufacturing Process",
    "Policy",
    "Supplier",
    "Other"
  ];

  const allowedAreas = [
    "Product",
    "R&D",
    "IT",
    "Manufacturing",
    "Quality",
    "Cross-functional"
  ];

  const allowedRisks = ["Low", "Moderate", "High", "Unknown"];
  const allowedPriorities = ["Standard", "Expedited", "Emergency"];
  const allowedRollback = ["Yes", "No", "Unknown"];
  const allowedCosts = [
    "Under 500",
    "500 to 2,499",
    "2,500 to 9,999",
    "10,000 or more",
    "Unknown"
  ];

  if (!isAllowed(changeType, allowedTypes)) {
    errors.push("Change type is not allowed.");
  }

  if (!isAllowed(affectedArea, allowedAreas)) {
    errors.push("Affected area is not allowed.");
  }

  if (!isAllowed(initialRisk, allowedRisks)) {
    errors.push("Initial risk is not allowed.");
  }

  if (!isAllowed(requestedPriority, allowedPriorities)) {
    errors.push("Requested priority is not allowed.");
  }

  if (!isAllowed(rollbackPossible, allowedRollback)) {
    errors.push("Rollback selection is not allowed.");
  }

  if (!isAllowed(costBand, allowedCosts)) {
    errors.push("Cost band is not allowed.");
  }

  let affectedUsers = "";
  if (affectedUsersRaw) {
    if (!/^\d+$/.test(affectedUsersRaw)) {
      errors.push("Affected users must be a non-negative whole number.");
    } else {
      affectedUsers = String(Number(affectedUsersRaw));
    }
  }

  const normalizedRiskSignals = riskSignals
    .split(",")
    .map((item) => item.trim())
    .filter(Boolean);

  if (
    normalizedRiskSignals.includes("None") &&
    normalizedRiskSignals.length > 1
  ) {
    errors.push("Risk signal None cannot accompany another risk signal.");
  }

  if (requestedPriority === "Emergency" && emergencyReason.length < 20) {
    errors.push("Emergency requests require a reason.");
  }

  if (rollbackPossible === "Yes" && rollbackApproach.length < 20) {
    errors.push("A rollback approach is required when rollback is possible.");
  }

  if (!attestation) {
    errors.push("Attestation is required.");
  }

  const evidenceCheck = validHttpsUrls(inputData.evidence_links);
  if (!evidenceCheck.valid) {
    errors.push("Every evidence link must use HTTPS.");
  }

  let desiredDate = "";
  if (desiredDateRaw) {
    const parsedDesiredDate = new Date(desiredDateRaw);
    if (Number.isNaN(parsedDesiredDate.getTime())) {
      errors.push("Desired implementation date is invalid.");
    } else if (
      !Number.isNaN(submittedAt.getTime()) &&
      parsedDesiredDate.getTime() < submittedAt.getTime() - 86400000
    ) {
      errors.push("Desired implementation date precedes submission.");
    } else {
      desiredDate = parsedDesiredDate.toISOString();
    }
  }

  if (!spreadsheetId || !rowNumber) {
    errors.push("Spreadsheet ID and source row identifier are required.");
  }

  const seed = [
    spreadsheetId,
    rowNumber,
    submittedAtRaw,
    requesterEmail,
    requestTitle
  ].join("|").toLowerCase();

  const hash = stableHash(seed);
  const dateForId = Number.isNaN(submittedAt.getTime())
    ? new Date()
    : submittedAt;

  const datePart = [
    dateForId.getUTCFullYear(),
    String(dateForId.getUTCMonth() + 1).padStart(2, "0"),
    String(dateForId.getUTCDate()).padStart(2, "0")
  ].join("");

  const changeId = `CR-${datePart}-${hash.slice(0, 6)}`;
  const sourceKey = `GF:${spreadsheetId}:${rowNumber}:${hash}`;
  const safeFolderTitle = requestTitle
    .replace(/[\\/:*?"<>|#%{}[\]]/g, "")
    .replace(/\s+/g, " ")
    .trim()
    .slice(0, 80);

  console.log(JSON.stringify({
    changeId,
    sourceKey,
    valid: errors.length === 0,
    errorCount: errors.length
  }));

  return {
    valid: errors.length === 0 ? "true" : "false",
    validation_errors: errors.join(" | "),
    change_id: changeId,
    source_submission_key: sourceKey,
    submitted_at_iso: Number.isNaN(submittedAt.getTime())
      ? ""
      : submittedAt.toISOString(),
    requester_email: requesterEmail,
    request_title: requestTitle,
    record_name: `${changeId} ${requestTitle}`,
    safe_folder_name: `${changeId} ${safeFolderTitle}`,
    change_type: changeType,
    affected_area: affectedArea,
    routing_key: `AREA:${affectedArea.toUpperCase()}`,
    business_reason: businessReason,
    current_state: currentState,
    proposed_change: proposedChange,
    affected_users: affectedUsers,
    risk_signals: normalizedRiskSignals.join(","),
    initial_risk: initialRisk,
    cost_band: costBand,
    requested_priority: requestedPriority,
    desired_date_iso: desiredDate,
    success_criteria: successCriteria,
    test_idea: testIdea,
    rollback_possible: rollbackPossible,
    rollback_approach: rollbackApproach,
    evidence_links: evidenceCheck.normalized,
    emergency_reason: emergencyReason
  };
} catch (error) {
  console.log(error && error.stack ? error.stack : String(error));

  return {
    valid: "false",
    validation_errors: `Unexpected validation error: ${String(error.message || error)}`,
    change_id: "",
    source_submission_key: ""
  };
}

In the next Zapier step, use a path or filter where valid exactly equals true. The invalid branch updates Processing Status to Validation Failed and writes validation_errors to the source row.

Test the code with a normal row, a malformed email, a past date, an invalid cost band, conflicting risk signals, a non-HTTPS link, and a repeated source row. Repeating the same inputs must produce the same change ID and source key.

Status Transition Validation Code

Place this JavaScript action after the Notion update trigger and the filter confirming that Status differs from Last Logged Status. Map all listed fields from the current Notion record.

/*
Required inputData keys:
previous_status
requested_status
status_version
test_result
rollback_plan
rollback_owner
implementation_plan
implementation_owner
scheduled_at
business_approval
it_approval
operations_approval
final_approval
it_required
operations_required
implementation_result
closure_evidence
rollback_evidence
*/

function value(name) {
  return String(inputData[name] || "").trim();
}

function isTrue(name) {
  return ["true", "yes", "1"].includes(value(name).toLowerCase());
}

function hasMinimum(name, length) {
  return value(name).length >= length;
}

try {
  const previous = value("previous_status");
  const current = value("requested_status");
  const reasons = [];

  const transitions = {
    "Submitted": [
      "Needs Information",
      "Under Impact Review",
      "Rejected"
    ],
    "Needs Information": [
      "Under Impact Review",
      "Rejected",
      "On Hold"
    ],
    "Under Impact Review": [
      "Planned",
      "Needs Information",
      "Rejected",
      "On Hold"
    ],
    "Planned": [
      "Testing",
      "Needs Information",
      "Rejected",
      "On Hold"
    ],
    "Testing": [
      "Awaiting Approval",
      "Planned",
      "Needs Information",
      "On Hold"
    ],
    "Awaiting Approval": [
      "Approved / Scheduled",
      "Needs Information",
      "Rejected",
      "Planned",
      "On Hold"
    ],
    "Approved / Scheduled": [
      "Implementing",
      "Planned",
      "On Hold"
    ],
    "Implementing": [
      "Monitoring",
      "Rolled Back"
    ],
    "Monitoring": [
      "Closed",
      "Rolled Back",
      "Planned"
    ],
    "Rolled Back": [
      "Closed",
      "Planned"
    ],
    "On Hold": [
      "Under Impact Review",
      "Planned",
      "Testing",
      "Awaiting Approval",
      "Approved / Scheduled",
      "Rejected"
    ],
    "Rejected": [],
    "Closed": []
  };

  if (!Object.prototype.hasOwnProperty.call(transitions, previous)) {
    reasons.push(`Unknown previous status: ${previous}`);
  } else if (!transitions[previous].includes(current)) {
    reasons.push(`Transition from ${previous} to ${current} is not allowed.`);
  }

  if (current === "Awaiting Approval") {
    if (!["Pass", "Conditional Pass"].includes(value("test_result"))) {
      reasons.push("Testing must pass or conditionally pass before approval.");
    }
    if (!hasMinimum("rollback_plan", 40)) {
      reasons.push("Rollback plan must contain at least 40 characters.");
    }
    if (!value("rollback_owner")) {
      reasons.push("Rollback owner is required.");
    }
    if (!hasMinimum("implementation_plan", 40)) {
      reasons.push("Implementation plan must contain at least 40 characters.");
    }
    if (!value("implementation_owner")) {
      reasons.push("Implementation owner is required.");
    }
  }

  if (current === "Approved / Scheduled") {
    if (value("business_approval") !== "Approved") {
      reasons.push("Business approval is required.");
    }
    if (isTrue("it_required") && value("it_approval") !== "Approved") {
      reasons.push("IT approval is required.");
    }
    if (
      isTrue("operations_required") &&
      value("operations_approval") !== "Approved"
    ) {
      reasons.push("Operations or quality approval is required.");
    }
    if (value("final_approval") !== "Approved") {
      reasons.push("Final coordinator approval is required.");
    }
  }

  if (current === "Implementing") {
    if (!value("scheduled_at")) {
      reasons.push("Scheduled implementation time is required.");
    }
    if (value("final_approval") !== "Approved") {
      reasons.push("Final approval is required before implementation.");
    }
  }

  if (current === "Monitoring") {
    const allowedResults = [
      "Implemented",
      "Implemented with Observation"
    ];
    if (!allowedResults.includes(value("implementation_result"))) {
      reasons.push("Implementation result is required before monitoring.");
    }
  }

  if (current === "Closed" && !hasMinimum("closure_evidence", 20)) {
    reasons.push("Closure evidence must contain at least 20 characters.");
  }

  if (current === "Rolled Back" && !hasMinimum("rollback_evidence", 20)) {
    reasons.push("Rollback evidence must contain at least 20 characters.");
  }

  const currentVersion = Number(value("status_version") || "0");
  const nextVersion = Number.isFinite(currentVersion)
    ? currentVersion + 1
    : 1;

  const reminderHoursByStatus = {
    "Submitted": 24,
    "Needs Information": 48,
    "Under Impact Review": 48,
    "Planned": 48,
    "Testing": 48,
    "Awaiting Approval": 24,
    "Approved / Scheduled": 24,
    "Implementing": 4,
    "Monitoring": 24,
    "On Hold": 168
  };

  const reminderHours = reminderHoursByStatus[current] || 0;
  const now = new Date();
  const reminderAt = reminderHours
    ? new Date(now.getTime() + reminderHours * 3600000).toISOString()
    : "";

  return {
    allowed: reasons.length === 0 ? "true" : "false",
    validation_reason: reasons.join(" | "),
    from_status: previous,
    to_status: current,
    next_status_version: String(nextVersion),
    status_entered_at: now.toISOString(),
    reminder_at: reminderAt,
    escalation_at: reminderHours
      ? new Date(now.getTime() + reminderHours * 2 * 3600000).toISOString()
      : ""
  };
} catch (error) {
  console.log(error && error.stack ? error.stack : String(error));

  return {
    allowed: "false",
    validation_reason: `Unexpected transition validation error: ${String(error.message || error)}`
  };
}

On the allowed path, create the Change Event before updating Last Logged Status. On the blocked path, create a Transition Blocked event, restore Status to the previous value, set Automation Status to Manual Review, and notify the coordinator.

The code uses calendar hours. If reminders must exclude weekends or organizational holidays, replace the date calculation with an approved business-calendar service or maintain calculated reminder dates in the workflow.

Native Zap Configuration Summary

Use platform retry settings for transient actions where available. Retry behavior differs by connector and failure type, so verify the behavior in the current Zapier run history. Do not assume that every failed action is automatically replayed.

Inspect Zapier run history for input, output, action duration, and error details. Inspect Notion’s Automation Failures view and the source spreadsheet for records that remain Pending. Avoid copying credentials or sensitive payloads into support tickets or Slack alerts.

Failure Handling and Operational Reliability

Idempotency is applied at three levels:

• The intake source key prevents repeated form-row processing from creating another request.
• The decision source key prevents the same approval row from creating another decision event.
• Status Version prevents delayed reminder runs from acting on obsolete workflow states.

The source spreadsheets function as a lightweight dead-letter queue. Rows marked Validation Failed, Retry Pending, or Manual Review remain available until resolved. They are never silently deleted.

A daily reconciliation checks for intake rows older than 15 minutes with no Notion Page ID, decision rows with no Event ID, Notion requests in Pending for more than 30 minutes, and requests whose Status differs from Last Logged Status.

A Complete Example

An R&D engineer at Alder Vale Instruments requests a change to the calibration-rejection threshold used by a firmware component and a manufacturing test station.

The engineer submits the following information through Google Forms:

• Title: Adjust calibration rejection threshold for sensor module
• Change type: Product
• Affected area: Cross-functional
• Business reason: Valid units near the tolerance boundary are being rejected and reworked.
• Affected users: 14 production operators and four quality employees
• Risk signals: Quality and Downtime
• Initial risk: Moderate
• Cost band: 2,500 to 9,999
• Priority: Standard
• Success criteria: Reduce false rejects without accepting out-of-tolerance modules.
• Rollback approach: Restore the signed prior firmware configuration and test-station threshold package.

The intake Zap validates the response and generates CR-20260715-7A31C2. It creates a source key tied to the spreadsheet row, confirms that no Notion record has that key, retrieves the cross-functional routing rule, and creates a Drive folder named CR-20260715-7A31C2 Adjust calibration rejection threshold for sensor module.

Zapier creates the Notion record with Submitted status, assigns the product operations manager as coordinator, assigns an R&D lead as technical owner, and identifies an operations or quality reviewer as required. The Notion page ID and Drive URL are returned and written to the source spreadsheet.

A submission event is created. Slack receives a message containing the change ID, title, Moderate initial risk, Quality and Downtime signals, coordinator, and Notion link.

During impact review, the technical owner identifies dependencies on firmware versioning, the manufacturing test-station configuration, work instructions, and quality sampling. The approved risk remains Moderate. Expected production downtime is 20 minutes.

The owner creates a Test Run related to the change. Thirty representative units are tested, including units near both tolerance boundaries. The test result is Pass, and the evidence file is stored in the Drive folder.

The owner completes the implementation sequence, rollback trigger, rollback steps, verification checks, and monitoring period. Moving the record to Awaiting Approval passes transition validation.

The business owner and operations or quality reviewer receive Slack notifications. Each submits the approval form using the change ID. Zapier verifies each responder email, creates separate decision events, and updates the corresponding approval fields.

The final coordinator reviews the test evidence, cost, downtime, rollback package, and prior approvals. The coordinator submits an Approve decision. The request moves to Approved / Scheduled and is scheduled for the next planned maintenance window.

At implementation time, the owner installs the signed configuration package, updates the test station, verifies version identifiers, and records the external firmware package ID in Notion. The status changes to Implementing and then Monitoring.

The team monitors two production shifts. The false-reject rate improves within the pre-agreed success criteria, no out-of-tolerance units are accepted, and no rollback trigger occurs.

The coordinator adds monitoring evidence and closure notes. The transition to Closed creates the final event and Slack notification. The result is one connected record containing the request, impact review, tests, approvals, implementation evidence, rollback readiness, event history, and final outcome.

Implementation Cost

The following amounts are representative planning assumptions, not verified client results or vendor price quotations. Current licensing, task limits, regional pricing, taxes, and existing agreements must be checked directly with each provider.

A company implementing with internal staff would replace the professional implementation line with its own loaded labour cost. Free or already licensed tools still require configuration, testing, support, permission review, and maintenance.

Estimated Time and Cost Savings

The representative calculation uses these assumptions:

• 28 change requests per month
• 105 minutes of administrative handling per request in the original process
• 32 minutes per request after core automation
• 15 percent exception rate
• 20 minutes of manual work per exception
• 2.5 hours of monthly workflow maintenance
• 48 loaded hourly labour cost
• 75 recurring monthly software cost
• 8,160 one-time implementation cost

Current monthly labour hours: Monthly volume × current minutes per record ÷ 60

New monthly labour hours: Monthly volume × new minutes per record ÷ 60, plus exception handling and maintenance

Monthly hours recovered: Current monthly labour hours minus new monthly labour hours

Estimated monthly labour value: Monthly hours recovered × loaded hourly labour cost

Net estimated monthly value: Monthly labour value minus recurring tool costs

Estimated payback period: One-time implementation cost ÷ net estimated monthly value

Recovered time does not automatically reduce payroll. It can represent additional capacity, quicker turnaround, reduced overtime, fewer administrative tasks, greater change volume without proportional coordination work, and lower dependence on individual employees.

Non-financial benefits include clearer ownership, fewer follow-up messages, more complete requests, earlier rollback planning, consistent approval evidence, faster status reporting, improved cross-department coordination, and a more reliable operational history.

Readers should replace the monthly volume, handling time, exception rate, labour rate, task volume, software allowance, implementation effort, and maintenance time with their own measurements.

Adding AI to the Automation

AI is optional and should be added only after intake validation, ownership, testing, approvals, status control, and failure handling work reliably.

Normal automation already creates records, routes requests, creates folders, sends notifications, enforces required fields, validates status transitions, records decisions, and schedules reminders. AI is not needed for those deterministic tasks.

Potential AI uses include summarizing long requests, suggesting affected domains, identifying missing impact-analysis topics, proposing test considerations, comparing a proposed change with prior records, and highlighting rollback-plan gaps.

Exact matching, required approvers, cost thresholds, status transitions, permissions, due dates, and final decisions remain rule-based. These tasks are more reliable when implemented with forms, validations, lookup tables, and human authorization.

The Recommended AI Enhancement

The recommended enhancement is an impact-analysis assistant. It reads approved non-sensitive request fields and produces a structured draft for the technical owner. It does not assign final risk, approve the request, or authorize implementation.

• Trigger: A valid request enters Under Impact Review and AI Analysis Status is Not Started.
• AI input: Change type, affected area, business reason, current state, proposed change, affected groups, risk signals, cost band, success criteria, initial test idea, and rollback information.
• System instruction: Analyze only the supplied content, distinguish facts from suggestions, and return the required JSON.
• Expected output: Summary, affected domains, missing information, risk questions, test suggestions, rollback gaps, and confidence.
• Validation: Parse JSON, validate required keys, enforce enumerated domains, cap array lengths, and reject unstructured output.
• Record update: Save the draft in AI Impact Summary fields with status Awaiting Human Review.
• Human review: Technical owner accepts, edits, or rejects every suggestion.
• Low confidence: Confidence below 0.70 routes the record to normal manual impact analysis without using the draft as evidence.
• Prohibited data: Credentials, secrets, personal records, detailed vulnerabilities, regulated data, and unnecessary customer content.
• Failure behavior: Record AI Analysis Status as Failed and continue with manual review.

The request can be sent to the OpenAI Responses API or another approved structured-output service. If OpenAI is selected, use the official Responses API documentation to confirm the current model, request fields, and supported structured-output features.

Reusable System Prompt

You are an impact-analysis assistant for controlled product, system, and manufacturing-process changes.

Analyze only the information supplied by the user. Do not invent systems, users, costs, legal requirements, test results, approvals, or facts.

Separate observed facts from suggested review questions. Identify missing information, possible affected domains, test considerations, and rollback-plan gaps.

Do not make a final risk decision. Do not approve or reject the change. Do not authorize implementation. Do not provide a legal, safety, security, privacy, or regulatory conclusion.

Return only JSON matching the supplied schema. Keep each list concise and actionable. If information is insufficient, state the gap rather than guessing.

Reusable User Prompt

Change ID: {{Change ID}}
Change type: {{Change Type}}
Affected area: {{Affected Area}}
Business reason: {{Business Reason}}
Current state or problem: {{Current State}}
Proposed change: {{Proposed Change}}
Affected user groups: {{Affected User Groups}}
Estimated affected users: {{Affected Users}}
Risk signals selected by requester: {{Risk Signals}}
Initial risk selected by requester: {{Initial Risk}}
Estimated cost band: {{Cost Band}}
Requested priority: {{Requested Priority}}
Success criteria: {{Success Criteria}}
Initial test idea: {{Initial Test Idea}}
Rollback possible: {{Rollback Possible}}
Initial rollback approach: {{Rollback Approach}}

Produce a factual summary, affected-domain suggestions, missing information, risk questions, test suggestions, rollback gaps, and a confidence value from 0 to 1. Confidence measures whether the supplied information is sufficient to create useful review suggestions, not whether the change is safe or should be approved.

Structured Output Schema

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "factual_summary": {
      "type": "string"
    },
    "affected_domains": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": [
          "product",
          "research_and_development",
          "information_technology",
          "manufacturing",
          "quality",
          "security",
          "privacy",
          "supplier",
          "customer",
          "finance",
          "regulatory",
          "unknown"
        ]
      },
      "maxItems": 12
    },
    "missing_information": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "maxItems": 10
    },
    "risk_questions": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "maxItems": 10
    },
    "test_suggestions": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "maxItems": 10
    },
    "rollback_gaps": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "maxItems": 10
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    }
  },
  "required": [
    "factual_summary",
    "affected_domains",
    "missing_information",
    "risk_questions",
    "test_suggestions",
    "rollback_gaps",
    "confidence"
  ]
}

Configure the Zapier webhook action as follows. Store the API key in a restricted application connection or approved secret mechanism rather than in a shared record.

Method: POST
URL: https://api.openai.com/v1/responses

Headers:
Authorization: Bearer YOUR_OPENAI_API_KEY
Content-Type: application/json

Timeout behavior:
On timeout or non-success response, mark AI Analysis Status as Failed.
Do not block the normal impact-review workflow.

Model:
YOUR_APPROVED_MODEL

The exact request body depends on the approved model and current API specification. A representative structured request is:

{
  "model": "YOUR_APPROVED_MODEL",
  "input": [
    {
      "role": "system",
      "content": [
        {
          "type": "input_text",
          "text": "You are an impact-analysis assistant for controlled product, system, and manufacturing-process changes. Analyze only supplied information. Do not make final risk, approval, legal, safety, security, privacy, or regulatory decisions. Return only JSON matching the schema."
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "Change ID: {{Change ID}}\nChange type: {{Change Type}}\nAffected area: {{Affected Area}}\nBusiness reason: {{Business Reason}}\nCurrent state: {{Current State}}\nProposed change: {{Proposed Change}}\nAffected users: {{Affected Users}}\nRisk signals: {{Risk Signals}}\nCost band: {{Cost Band}}\nSuccess criteria: {{Success Criteria}}\nTest idea: {{Initial Test Idea}}\nRollback approach: {{Rollback Approach}}"
        }
      ]
    }
  ],
  "text": {
    "format": {
      "type": "json_schema",
      "name": "change_impact_assessment",
      "strict": true,
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "factual_summary": {
            "type": "string"
          },
          "affected_domains": {
            "type": "array",
            "items": {
              "type": "string",
              "enum": [
                "product",
                "research_and_development",
                "information_technology",
                "manufacturing",
                "quality",
                "security",
                "privacy",
                "supplier",
                "customer",
                "finance",
                "regulatory",
                "unknown"
              ]
            },
            "maxItems": 12
          },
          "missing_information": {
            "type": "array",
            "items": {
              "type": "string"
            },
            "maxItems": 10
          },
          "risk_questions": {
            "type": "array",
            "items": {
              "type": "string"
            },
            "maxItems": 10
          },
          "test_suggestions": {
            "type": "array",
            "items": {
              "type": "string"
            },
            "maxItems": 10
          },
          "rollback_gaps": {
            "type": "array",
            "items": {
              "type": "string"
            },
            "maxItems": 10
          },
          "confidence": {
            "type": "number",
            "minimum": 0,
            "maximum": 1
          }
        },
        "required": [
          "factual_summary",
          "affected_domains",
          "missing_information",
          "risk_questions",
          "test_suggestions",
          "rollback_gaps",
          "confidence"
        ]
      }
    }
  }
}

After the webhook, use a JavaScript code action to locate the message output, parse the JSON text, and validate key fields before updating Notion.

/*
Map the complete webhook response body to:
inputData.response_json
*/

const allowedDomains = new Set([
  "product",
  "research_and_development",
  "information_technology",
  "manufacturing",
  "quality",
  "security",
  "privacy",
  "supplier",
  "customer",
  "finance",
  "regulatory",
  "unknown"
]);

function assertString(value, name) {
  if (typeof value !== "string" || !value.trim()) {
    throw new Error(`${name} must be a non-empty string.`);
  }
  return value.trim();
}

function assertStringArray(value, name, maxItems) {
  if (!Array.isArray(value)) {
    throw new Error(`${name} must be an array.`);
  }
  if (value.length > maxItems) {
    throw new Error(`${name} exceeds ${maxItems} items.`);
  }
  return value.map((item) => assertString(item, name));
}

try {
  const response = typeof inputData.response_json === "string"
    ? JSON.parse(inputData.response_json)
    : inputData.response_json;

  if (!response || !Array.isArray(response.output)) {
    throw new Error("Response does not contain an output array.");
  }

  const message = response.output.find(
    (item) => item && item.type === "message"
  );

  if (!message || !Array.isArray(message.content)) {
    throw new Error("Response does not contain a message output.");
  }

  const textPart = message.content.find(
    (item) => item && item.type === "output_text"
  );

  if (!textPart || typeof textPart.text !== "string") {
    throw new Error("Response does not contain output_text.");
  }

  const parsed = JSON.parse(textPart.text);
  const factualSummary = assertString(
    parsed.factual_summary,
    "factual_summary"
  );

  const affectedDomains = assertStringArray(
    parsed.affected_domains,
    "affected_domains",
    12
  );

  const invalidDomain = affectedDomains.find(
    (domain) => !allowedDomains.has(domain)
  );

  if (invalidDomain) {
    throw new Error(`Unsupported affected domain: ${invalidDomain}`);
  }

  const missingInformation = assertStringArray(
    parsed.missing_information,
    "missing_information",
    10
  );

  const riskQuestions = assertStringArray(
    parsed.risk_questions,
    "risk_questions",
    10
  );

  const testSuggestions = assertStringArray(
    parsed.test_suggestions,
    "test_suggestions",
    10
  );

  const rollbackGaps = assertStringArray(
    parsed.rollback_gaps,
    "rollback_gaps",
    10
  );

  const confidence = Number(parsed.confidence);
  if (!Number.isFinite(confidence) || confidence < 0 || confidence > 1) {
    throw new Error("confidence must be between 0 and 1.");
  }

  return {
    valid: "true",
    factual_summary: factualSummary,
    affected_domains: affectedDomains.join(", "),
    missing_information: missingInformation.join("\n"),
    risk_questions: riskQuestions.join("\n"),
    test_suggestions: testSuggestions.join("\n"),
    rollback_gaps: rollbackGaps.join("\n"),
    confidence: String(confidence),
    review_status: confidence >= 0.7
      ? "Awaiting Human Review"
      : "Low Confidence Manual Review"
  };
} catch (error) {
  console.log(error && error.stack ? error.stack : String(error));

  return {
    valid: "false",
    error_message: String(error.message || error),
    review_status: "Failed"
  };
}

Test with normal output, missing keys, an unsupported domain, confidence outside the permitted range, non-JSON text, an API error, and an empty response. A failed AI action must never prevent manual impact review.

Benefits of the AI Enhancement

The AI-specific benefit is reduced reading and drafting time for unstructured change descriptions. It can create a consistent first-pass summary, identify review topics that may have been omitted, and suggest test or rollback questions for the owner to consider.

It does not provide the core benefits of record creation, notifications, approvals, history, ownership, evidence storage, or deterministic workflow control. Those benefits already exist without AI.

Potential AI-specific improvements include:

• Less time spent converting long descriptions into a review summary
• More consistent identification of potentially affected domains
• Earlier detection of missing dependency or rollback information
• Quicker preparation for cross-functional review meetings
• More consistent language for reporting categories

What Remains Rule-Based or Human-Controlled

• Final risk rating: Human reviewers understand operational context and are accountable for the accepted risk.
• Test acceptance: A test owner verifies evidence and determines whether results satisfy the approved criteria.
• Safety and quality conclusions: Qualified employees apply policy, standards, and product knowledge.
• Security and privacy decisions: Authorized IT or privacy reviewers determine required controls.
• Cost approval: Budget owners approve expenditure according to company authority.
• Final change approval: The designated coordinator confirms that required evidence and approvals are complete.
• Implementation authorization: The implementation owner and coordinator confirm schedule, dependencies, and readiness.
• Rollback decision: Accountable employees evaluate observed conditions against the documented trigger.
• Closure: The coordinator verifies outcome and evidence before closing the request.

AI suggestions are stored separately from human-approved fields. Accepting an AI summary does not update Approved Risk, Approval Status, Test Result, Implementation Authorization, or final Status.

Estimating the Additional Value of AI

The representative AI estimate uses 28 requests per month. Routine human review of AI output is included in a net six-minute saving per request compared with the core automation. Additional correction and failure time is then deducted.

The AI estimate assumes a 20 percent correction rate and 5 percent service or parsing failure rate. It does not assume error-free output or removal of human review. The main justification may be review consistency and capacity rather than direct financial return.

Testing Checklist

Use sample data and test accounts before processing real operational or sensitive information.

Ongoing Maintenance

The product operations manager is the primary business owner. The automation specialist or IT service lead is the technical owner, with a named backup for both roles.

Changes to form fields, Notion property names, select values, folder locations, Slack channels, or approval roles can break mappings. Treat workflow configuration changes as controlled changes and test them before activation.

Maintain a versioned configuration register containing Zap names, owners, trigger sources, destination databases, field mappings, connection owners, test dates, and current recovery procedures.

When to Move to Dedicated Software

The implementation should not be replaced merely because dedicated products exist. It remains appropriate while volume, permissions, workflow complexity, and support requirements fit the selected tools.

Consider a dedicated change-management, IT service management, product lifecycle management, manufacturing execution, or quality-management platform when several of these conditions appear:

• Monthly volume grows enough that Zapier task usage, Notion database performance, or manual exception review becomes burdensome.
• Multiple sites require different calendars, approval authorities, data boundaries, or local workflows.
• Formal regulations require validated electronic signatures, prescribed records, or stronger audit controls.
• Field-level security and complex segregation of duties become mandatory.
• Changes must connect directly to assets, configuration items, bills of material, source control, deployment pipelines, maintenance systems, or production equipment.
• Exception rates increase because the workflow has too many conditional paths.
• Administrators spend excessive time repairing mappings or reconciling data.
• Customers or suppliers require external portals.
• Mobile or offline operation becomes necessary.
• Advanced capacity planning, portfolio reporting, dependency mapping, or release coordination is required.
• Formal vendor support, uptime commitments, or validated recovery procedures become necessary.
• The security impact of several connected cloud applications exceeds the organization’s accepted risk.

Before migrating, use the event history and exception data to define real requirements. Stable IDs, structured fields, Drive evidence, and explicit status history make later migration easier.

Implementation Checklist

• Confirm change types, volume, departments, risks, and approval rules.
• Confirm Google Forms, Google Sheets, Notion, Zapier, Slack, and Google Drive as the selected tools.
• Create organization-owned accounts and named backup owners.
• Apply least-privileged permissions to databases, folders, forms, channels, and integrations.
• Build Change Requests, Change Events, Test Runs, and Routing Rules databases.
• Define stable change IDs, source keys, event IDs, and status versions.
• Build and validate the intake form.
• Build the authenticated approval form.
• Create source-ledger processing and error columns.
• Configure Notion templates, relations, views, and calculated fields.
• Map every source field to its destination property.
• Configure routing, duplicate checks, record creation, folder creation, and source updates.
• Configure status validation and append-only event creation.
• Configure approval rules, reviewer verification, rejection, and return-for-information paths.
• Configure reminders, stale-run checks, escalations, and delegation.
• Configure restricted Slack notifications.
• Configure Drive folder structure, naming, permissions, versioning, retention, and archiving.
• Create operational, overdue, exception, rollback, and automation-failure views.
• Install and test the JavaScript validation and transition code.
• Test normal, invalid, duplicate, failed, unauthorized, rejected, rolled-back, and completed records.
• Run user acceptance testing with each participating department.
• Document deployment, support, reconciliation, replay, and workflow rollback procedures.
• Record representative software, labour, maintenance, and savings assumptions.
• Add the optional AI enhancement only after the core workflow is reliable.
• Validate AI schema, confidence handling, prohibited data, human review, and fallback behavior.
• Name the business owner, technical owner, and backup owner.
• Schedule failed-run, permission, credential, cost, retention, and documentation reviews.
• Define measurable criteria for moving to dedicated software.