#Lookup Users to resolve the manager record from $employee.managerEmail.

Determine the buddy:

• #Search Graph the HR ingest for active team members on $employee.team with tenure >6 months.

• Pick one not already buddying for someone else; capture buddy email.

Pre-day-1 (fires immediately on webhook):

• #Send Email to $employee.personalEmail with the welcome packet: handbook link, benefits enrollment link, day-1 logistics, dress code, what-to-bring, parking/transit info, manager intro.

• Attach the team intro doc and the location-specific office welcome PDF.

Day-1 calendar (fires 3 business days before $employee.startDate):

• #Custom Google Calendar Create Event for a 30-min day-1 manager intro at 10:00 AM local on $employee.startDate. Invite $employee.email, manager, and HRBP.

• #Custom Google Calendar Create Event for buddy lunch at 12:30 PM local on day 2. Invite $employee.email and the buddy.

• #Custom Google Calendar Create Event for HR orientation at 2:00 PM local on day 1.

• #Custom Google Calendar Create Event for day-1 IT setup walkthrough at 9:00 AM local.

Slack onboarding (fires on $employee.startDate at 9:00 AM local):

• #Add Users To Channel for #welcome, #all-hands, #{{team}}, and #{{location}}-office.

• #Send Channel Message to #welcome introducing the new hire with their preferred name, title, team, fun fact (collected via pre-start form if available), and a "say hi" prompt.

Team channel intro:

• #Send Channel Message to #{{team}} with a fuller bio and the manager tagged.

Manager + buddy nudge:

• #Send Direct Message to the manager: pre-start checklist (set up 1:1 cadence, prep first-week agenda, intro to key collaborators).

• #Send Direct Message to the buddy: their role (informal questions, lunch on day 2, check-in at end of week 1).

schedule_action wake at end of day 1 to confirm with the new hire via #Send Direct Message: "How did day 1 go? Anything blocking you?"

#Leave Internal Note capturing manager, buddy, calendar event IDs

#Search Okta User by Email for the requester to confirm the account exists and get the user ID.

#Search Okta System Log Custom for user.account.reset_password and user.mfa.factor.reset events in the last 30 days for this user.

#List User Factors to see current enrollments.

Risk score the request based on:

• 3+ resets in last 30 days → High

• Login from new country or unusual IP in last 24h → High

• Standard request from known device/location → Low

• Recent suspicious activity in Okta log → Medium

Identity verification per risk:

• Low → ask 2 security questions inline (custom action to check answers against profile).

• Medium → #Request Approval from the requester's manager (configured with requestersManager) confirming they spoke to the user.

• High → #Prompt for Handoff to a security team member for live video ID verification.

If verification fails or is denied: #Send Direct Message to the requester explaining next steps, #Send Channel Message to #sec-alerts, and #Resolve Request. Stop.

Execute the reset based on the issue type:

• Password reset → #Reset Password (Okta) with sendEmail = true.

• MFA factor reset → identify the specific factor from step 3 and call #Reset User Factor with that factor ID.

• Full factor wipe (lost device) → #Reset User Factors (Custom) to clear all factors so the user re-enrolls.

• Account locked → #custom Okta Unlock User action.

#Send Direct Message to the requester with confirmation and next-step instructions.

If risk was High OR pattern-flag triggered (3+ resets): #Send Channel Message to #sec-alerts with the user, the reason, and the action taken.

#Leave Internal Note on the request capturing risk score, verification method, and action taken.

#Resolve Request.

Parse the target Zip resource and role (viewer / requester / approver / buyer / admin) and justification. If role or resource is ambiguous → #Send Direct Message to the requester with a #Trigger Form to disambiguate; do not guess.

#Lookup Users on $requester.email with includeManager, includeGroups.

Idempotency / current-state check:

• #Zip Get User Roles for the requester on the target resource.

• If they already hold the role → #Send Direct Message confirming they already have it (with the Zip link) and #Resolve Request. Exit.

Validate eligibility:

• #Zip Get Role Policy for the requested role → eligible holders, required approver.

• If requester is ineligible for the role at all (e.g. contractor requesting admin) → #Send Direct Message with the reason + who can sponsor an exception; #Resolve Request. Exit.

• Admin/buyer → require elevated approval in step 5.

Approval:

• #Request Approval from the Zip resource owner (or requester's manager per policy).

• Denied → #Send Direct Message to requester with the reason; #Leave Internal Note; #Resolve Request. Exit.

Grant access:

• #Zip Grant Role for the requester on the resource.

• If the grant API call fails → #Create Linear Issue for the Zip admin with the full request + error, #Send Direct Message to requester ("routed to an admin, they'll finish this"), and continue to step 7 tracking the ticket instead of the API result.

Mirror the conversation:

• #Leave Internal Note with ticket/grant updates; #Send Direct Message for requester-facing status.

On grant confirmation (API success or ticket closed):

• #Send Direct Message to the requester with what was granted + Zip link + first-use note.

#Send Channel Message to #procurement-access for the log.

#Leave Internal Note capturing role, approver, grant method, ticket link.

#Resolve Request.

Filter:

• Only auto-investigate severity high / critical; lower → #Leave Internal Note to #obs-noise and exit.

Dedup / alert-storm guard:

• #Get Recent Investigations for $alert.service + $alert.fingerprint in the last 30 min.

• If an investigation already ran for the same fingerprint → append this occurrence to the existing incident thread via #Send Channel Message ("still firing, Nth occurrence") and exit; do not run a full duplicate RCA.

Resolve the service context:

• #Get Service Metadata for owning team, runbook, dependencies. If service is unmapped → #Send Channel Message to #obs-triage flagging the unknown service, run steps 4-6 best-effort anyway.

Pull golden signals from Grafana around $alert.startsAt:

• #Grafana Query Latency (p50/p95/p99).

• #Grafana Query Error Rate.

• #Grafana Query Saturation (CPU/mem/queue depth).

• #Grafana Query Traffic (RPS).

• If any query fails/times out → note "signal unavailable" in the report rather than aborting.

Pull recent changes:

• #GitHub Recent Deploys for the service in the last 6 hours.

• #Get Recent Config Changes / feature-flag flips.

Correlate:

• Compare each signal to baseline; flag which breached and when.

• Line up breach time vs deploy/config-change time to suggest a likely cause.

• "Signals normal" path: if nothing breached baseline → report as "alert fired but golden signals nominal — possible flapping/threshold issue" and suggest tuning the alert.

Compose the RCA-style report:

• What fired, when, abnormal signals (or "all nominal"), correlated change, affected dependencies, suggested next step + runbook link.

Deliver:

• #Send Channel Message to the service's incident channel, or #Create Channel #inc-{{service}}-{{ts}} with the report.

• If tied to PagerDuty → #PagerDuty Add Note with the summary.

Escalation:

• If signals point to a specific deploy → #Send Direct Message to the deploy author + on-call with a rollback suggestion.

• If signals nominal → #Send Direct Message to the alert owner suggesting threshold review.

#Create Linear Issue for the post-incident retro with the auto-investigation attached.

#Leave Internal Note capturing fingerprint (for dedup), signals, correlation.

#Lookup Users on the requester with includeManager.

#List Devices (Kandji) filtered by assignedUserEmail = requester.email to find their device(s).

If multiple devices, #Trigger Form to ask which device.

#Get Device Details (Kandji) to confirm the device is enrolled and active.

Risk check: #Search Okta System Log Custom for recent suspicious activity. If anomalous, escalate to Sec-12 flow.

Identity verification:

• #Request Approval from the requester's manager confirming the user is who they say they are.

• For high-risk cases (recent termination flag, device marked lost, off-hours request from new IP) → #Prompt for Handoff to security.

On approval: #Get Device FileVault Recovery Key (Kandji) for Mac, or custom Get BitLocker Recovery Key for Windows.

#Send Direct Message to the requester with:

• The recovery key

• Step-by-step unlock instructions (different for Mac vs Windows)

• Reminder to reset their password after unlock

Wait for the requester to confirm they're back in via a follow-up message.

After confirmation, #Send Direct Message suggesting they update their password and re-enroll FileVault/BitLocker.

#Leave Internal Note capturing device serial, verification method, and outcome.

#Resolve Request.

Parse target system, role/entitlement, duration, and justification from the request.

#Lookup Users on the requester with includeManager and includeGroups.

#Trigger Form to collect:

• Target system (dropdown of JIT-eligible systems)

• Specific role or scope (e.g. "AWS prod read-only", "Snowflake admin")

• Duration (max 8 hours, max 24 hours, max 7 days based on system tier)

• Business justification (free text, min 50 chars)

• Ticket/incident reference if responding to an incident

Validate the request:

• Requester is eligible for this system via custom Check JIT Eligibility.

• Duration is within max allowed for the system tier.

• Not already holding active JIT access for the same system.

Approval chain:

• #Request Approval from system owner (custom Get System Owner).

• #Request Approval from security on-call (custom Get Security Oncall).

• For top-tier systems (AWS root, prod DB): also #Request Approval from CISO or delegate.

On full approval:

• For Okta-managed → #Add to Group for the JIT entitlement group.

• For AWS → #custom AWS IAM Attach Policy with the specified role and a duration tag.

• For Snowflake → #custom Snowflake Grant Role with the role and the user.

• For app-specific → call the app's JIT grant action.

schedule_action wake at the TTL to execute revocation:

• Reverse of step 6 (Remove from Group / Detach Policy / Revoke Role).

#Send Direct Message to the requester with: access details, expiry timestamp, system access URL, what they can/cannot do.

#Send Channel Message to #security-jit logging the grant with: requester, system, role, duration, justification, ticket reference.

#Custom Vanta Log JIT Event with the full audit trail.

On revocation wake: #Send Direct Message to the requester confirming auto-expire; #Send Channel Message to #security-jit confirming revoke.

#Leave Internal Note capturing approval trail and grant/revoke timestamps.

Use #Lookup Users to resolve the manager record from $employee.managerEmail.

Determine the provisioning bundle based on $employee.department:

• Engineering → GitHub, Datadog, AWS sandbox

• Sales → Salesforce, Gong, Outreach, Sales Nav

• All → Okta, Google Workspace, Slack

Use #Create Okta User (Staged) with the email, first/last name, department, and manager.

Use #Activate Okta User to activate the account and send the activation email.

For each baseline group, call #Add to Group (Okta): all-employees, the department group, and the location group.

Use #Add to Group (Google) for all@, {{department}}@, and {{location}}@.

If $employee.department == "Engineering": #Invite User to Org (GitHub), #Add User to Team for the right team, #Invite User to Datadog, and grant AWS sandbox via #AWS IAM - List Attached User Policies + custom IAM attach.

If $employee.department == "Sales": invite to Salesforce, Gong, Outreach, Sales Nav (custom actions).

Use #Kandji Assign ADE Device User to pre-assign a device to $employee.email and ship to $employee.shippingAddress.

Use #List Google Calendar Events to find the manager's calendar, then create a day-1 intro event and a buddy lunch via Google Calendar.

Use #Invite to Channel to add the user to #welcome, #all-hands, and their team channel.

Use schedule_action to wake on Monday 9am $employee.location time to post a welcome thread in the team channel via #Send Channel Message.

Parse the request:

• Target object (deal / opportunity / contact / company / lead).

• Target identifier (deal name, ID, account name).

• Field to update.

• New value.

#Lookup Users on the requester with includeGroups.

Permission check:

• #Custom Check CRM Permission for the requester on the target object and field.

• Rep can update their own records.

• Manager can update reports' records.

• Ops can update any.

• If permission denied → #Request Approval from the record owner.

Locate the record:

• #Hubspot Search Deals (or #Search HubSpot Contacts, #Search HubSpot Companies) by name + owner.

• If multiple matches, #Send Direct Message with a disambiguation list via #Trigger Form.

#Get HubSpot Deal Details with Activity Timeline (or contact/company equivalent) to confirm current state.

Validate the new value:

• For owner changes: #Lookup Users to confirm the new owner exists.

• For close dates: must be future or current quarter unless requester is ops.

• For stage changes: must follow stage progression (route through Rev-15 if backward jump).

• For status changes: require closedLostReason if moving to closed-lost.

Confirm with the requester via #Send Direct Message showing the diff: "Will change {{field}} from {{old}} to {{new}}. Confirm?"

On confirm: #Update HubSpot Deal Properties (or custom Salesforce update action) with the new value.

Log the change:

• #Create HubSpot Note on Deal capturing who/what/when/why.

• #Send Channel Message to #revops-audit for high-impact changes (owner change, close-lost, stage skip).

#Send Direct Message to the requester confirming, including the deal link.

If the owner changed: #Send Direct Message to the new owner with the handoff.

#Leave Internal Note capturing the change and approval trail.

#Resolve Request.

Parse the quote ID and the reported symptom. Missing quote ID → #Trigger Form to collect.

#Lookup Users on the requester with includeGroups.

Pull the quote state:

• #CPQ Get Quote — line items, currency, contract association, pricing, discount, status.

• #CPQ Get Quote Errors — the actual validation/system errors.

• If quote not found or requester lacks access → #Send Direct Message with the reason; #Resolve Request. Exit.

• If quote has no errors and is valid → #Send Direct Message ("no errors detected — here's current state"); #Resolve Request. Exit.

Diagnose (read-only) across common failure modes:

• Currency mismatch (quote vs account vs price book).

• Missing/broken contract association.

• Expired or wrong price book.

• Product/option rule conflicts.

• Discount exceeding approved threshold.

• Missing required fields.

• Validation rule block.

Classify each finding:

• Fixable-by-config (relink price book, set currency, populate a field).

• Validation-rule block → escalate-only. Do NOT auto-bypass; surface which rule fired and why.

• Needs judgment (pricing/contract/legal implications) → escalate to deal desk.

• If the error is unrecognized / can't be diagnosed → #Send Direct Message to requester + #Send Channel Message to #deal-desk with the raw error; #Create Linear Issue for the CPQ admin. Exit the auto-fix path.

Propose the fix — do not apply:

• #Generate Fix Proposal describing each change (field, old → new value, rationale).

• #Send Direct Message to the requester (and deal desk for anything commercial) with the proposed diff and a #Trigger Form: Approve fix / Modify / Escalate to deal desk / Cancel.

• Cancel → #Leave Internal Note; #Resolve Request. Exit.

Human approval gate:

• Config-only fixes → requester or deal-desk approval.

• Anything touching pricing, discount, currency, or contract association → #Request Approval from deal desk.

• Denied → #Send Direct Message to requester with reason; exit.

Concurrency / staleness guard:

• #CPQ Get Quote again immediately before writing; if the quote changed since diagnosis (different lastModified) → re-run diagnosis and re-propose; do not apply a stale fix.

Apply only after approval:

• #CPQ Update Quote with the approved changes (scoped to the single quote — no batch writes).

• #CPQ Recalculate/Regenerate Quote to confirm the error clears.

• Re-run #CPQ Get Quote Errors to verify resolution.

• If the fix didn't clear the error → #Send Direct Message to requester + escalate to deal desk with the residual error; #Create Linear Issue for the CPQ admin.

For validation-rule blocks:

• #Send Direct Message to deal desk with the rule name + why it's blocking; do not modify the rule.

• If genuinely misconfigured → #Create Linear Issue for the CPQ admin (separate from this quote).

Confirm + log:

• #Send Direct Message to the requester with the outcome (fixed / escalated / needs admin).

• #Send Channel Message to #deal-desk-log with the quote + resolution.

• #Leave Internal Note capturing diagnosis, proposed fix, approval, applied changes, verification.

#Resolve Request.

Parse the repo + PR number/link. If missing → #Trigger Form to collect.

#Lookup Users on the requester with includeGroups.

Authorization / group check:

• #GitHub Check Team Membership — requester in the infra/devops-eligible team.

• If not → #Send Direct Message explaining self-serve isn't available; route to a manual DevOps approver via #Send Channel Message to #devops; continue in observer mode only.

Pull PR context:

• #GitHub Get PR for files changed, diff, checks status, existing approvals.

• If PR is already merged/closed → #Send Direct Message noting current state; #Resolve Request. Exit.

• If PR touches no Terraform files → note that; skip the TF-specific review and route to normal code review.

Run automated Terraform review:

• #Terraform Plan on PR (or read the CI plan output).

• If the plan fails to run (syntax error, state lock, CI failure) → #Send Direct Message to requester with the plan error; #Leave Internal Note; do NOT approve; #Resolve Request pending fix. Exit.

• #TF Policy Check (OPA/Sentinel/tflint) — flag public exposure, IAM broadening, destroy/replace of stateful resources, cost spikes.

• Summarize plan: resources to add/change/destroy.

Branch on review result:

• Clean + low-risk → #GitHub Approve PR (if policy allows) + post summary as a PR comment.

• Risky changes → do NOT auto-approve; post the flagged findings as a PR comment; #Send Direct Message to DevOps on-call + tag the PR for human review.

Drift guard:

• Note in the approval comment that approval is valid for the reviewed plan SHA; if new commits land after approval, the auto-approval is dismissed and re-review is required (#GitHub Dismiss Stale Approval on new push).

Poll for merge readiness:

• schedule_action wake to re-check checks/approvals; nudge requester if stalled >24h.

Notify:

• #Send Direct Message to the requester with review outcome, plan summary, next step.

For risky ones: #Send Channel Message to #devops with the PR + flagged findings.

#Leave Internal Note capturing plan SHA, summary, risk flags, approval decision.

#Resolve Request on merge/approval.

Parse the action type (create / add members / remove members / delete / change owner), target group name, downstream systems (Okta / Google / Slack / all), and member list.

Validate group name against naming convention (^[a-z][a-z0-9-]+$, max 40 chars). If invalid:

• #Send Direct Message explaining the rule and ask for a corrected name.

#Lookup Users on the requester with includeGroups.

Check authorization:

• Create → requester must be in the group-creators Okta group or an IT admin.

• Modify/Delete → requester must be the group owner OR an admin. Use #custom Get Group Owner action.

• If unauthorized → #Request Approval from an IT admin.

For Create:

• #Create Okta Group (Custom) with the name and description.

• #Create Group (Google) with the equivalent name ({{group}}@company.com).

• #Create Usergroup (Slack) with the handle @{{group}}.

• Set the requester as owner via custom Set Group Owner action.

For Add members:

• #Lookup Users for each member to resolve their IDs.

• For each: #Add to Group (Okta), #Add to Group (Google), #Add Usergroup Users (Slack).

For Remove members:

• For each: #Remove from Group (Okta), #Remove from Group (Google), #Remove Usergroup Users (Slack).

For Delete: confirm with the requester via #Trigger Form ("This will delete the group across all systems — confirm?"), then call custom delete actions for Okta + Google + Slack.

For role/manager-based sync (e.g. "add this week's new hires"): query the HR ingest via #Search Graph for matching users, then loop step 6.

#Send Direct Message to the requester with a summary of changes.

#Leave Internal Note capturing the action and downstream sync.

#Resolve Request.

Query the #custom Workday/HR ingest via #Search Graph for contractors with endDate between today + 5 days and today + 7 days.

For each contractor, #Lookup Users on the engagement owner's email with includeSlackId.

#Send Direct Message to the engagement owner with a #Trigger Form containing options: "Extend"(collect new end-date), "Expire on schedule", "Expire immediately".

Use schedule_action to wake 5 days later to check the form response.

On wake, branch on the response:

• Extend → #custom Workday Update Contractor End Date with the new date, then #Send Direct Message confirming.

• Expire on schedule or no response → schedule_action wake on the contractor's endDate to execute revocation.

• Expire immediately → execute revocation now.

Revocation sequence:

• #Search Okta User by Email to resolve the contractor's Okta ID.

• #Revoke All User Sessions (Okta).

• #Remove from Group (Okta) for every contractor-restricted group from the user's group list.

• #Remove User from Org (GitHub) to remove outside-collab status.

• #Custom Figma Revoke Member and Notion Revoke Guest actions.

• For each Slack guest channel: #Remove User From Channel.

#Create Linear Issue in the IT-Audit project documenting the revocation.

#Send Channel Message to #it-audit with the contractor name, owner, expiry type, and revoked entitlements.

#Lookup Users on the requester with includeManager and includeGroups to get role, department, location.

#Trigger Form to collect:

• Device type (laptop / monitor / accessory)

• Reason (new hire / refresh / replacement / additional)

• Specific model preference

• Shipping address (default to address on file)

• Needed-by date

#List Devices (Kandji) to check existing assigned devices and age.

Validate against role's approved spec:

• #Custom Zip Get Approved Spec action based on role.

• If requester is asking for an above-spec model, capture the justification.

Determine approval tier:

• <$2k → manager approval only.

• $2k–$5k → manager + finance approval.

• >$5k → manager + finance + VP approval.

#Request Approval chained per tier.

On approval, place the order:

• #Custom Zip Create Order with line items.

• #Custom CDW Place Order for actual procurement.

• Or #custom Apple Business Order for Apple direct.

Capture the tracking number from the order response.

schedule_action wake daily until delivered to:

• #Custom Get Shipping Status.

• #Send Direct Message with the latest status if it changed.

On delivery confirmation:

• #Kandji Assign ADE Device User to pre-assign the device.

• #Send Direct Message with first-time setup instructions.

#Leave Internal Note capturing model, price, approvers, tracking.

#Resolve Request on delivery + setup confirmation.

#Lookup Users on the requester with includeManager to get location.

#List Devices (Kandji) to identify their device(s).

#Trigger Form to collect:

• Symptom (drops / slow / can't connect / DNS / VPN)

• Office or remote

• When it started

• Frequency

Check upstream first:

• #List Meter Networks for the user's office.

• #Get Meter ISP Connectivity to confirm WAN is healthy.

• #Diagnose Meter Access Point for the AP they're connected to.

• If WAN or AP issue → escalate to networking (skip to step 9).

Check user-side:

• #Get Meter Client by MAC Address to see if the user's device is associated and healthy.

• #Search Okta System Log Custom for VPN/SSO failures in the last hour.

• #Get Device Details for Kandji-reported network config.

Attempt remediation:

• VPN drops → custom Re-establish VPN Tunnel action.

• DNS → #Create Kandji Custom Script to flush DNS cache and reset network interfaces.

• Slow → run iperf script via Kandji and compare to baseline.

Ask via #Send Direct Message if it's resolved after each remediation.

If resolved → #Resolve Request.

If unresolved or upstream issue: #Create Linear Issue in the networking project with the diagnostic bundle.

#Send Channel Message to #network-ops for upstream issues.

#Send Direct Message to the user with escalation and expected timeline.

#Leave Internal Note with full diagnostic trail.

#Trigger Form to collect:

• App name and vendor URL

• SSO protocol (SAML 2.0 / OIDC)

• For SAML: ACS URL, entity ID, name ID format, certificate

• For OIDC: redirect URI, scopes needed

• SCIM endpoint + bearer token (if available)

• Default user groups to provision (eng / product / design / all-company)

#Lookup Apps to confirm the app isn't already onboarded. If it exists, ask the requester whether to modify or reject.

#Request Approval from the security team for the new vendor (chain to Sec-18 if not already approved).

Create the Okta app:

• For SAML → custom Okta Create SAML App with ACS URL, entity ID, attributes mapping.

• For OIDC → custom Okta Create OIDC App with redirect URI and scopes.

#Create Okta Group (Custom) for default access: {{app-slug}}-users and {{app-slug}}-admins.

#Add to Group to assign the requester to {{app-slug}}-admins.

For each requested default group (eng/product/design/all-company): custom Okta Assign

Group to App to grant baseline access.

If SCIM endpoint provided: custom Okta Configure SCIM with the endpoint + token, then #Update 1Password App Username Template to set the username convention.

Generate test credentials via custom Okta Create Test User and Assign action.

#Send Direct Message to the requester with SSO sign-in URL, test creds, SCIM status, next steps.

#Create Linear Issue in the IT project for follow-up tasks: app catalog entry, access policy creation, KB doc.

#Leave Internal Note capturing the protocol, ACS URL, and groups configured.

#Resolve Request.

#Lookup Users on the requester with includeManager and includeGroups.

#Search Graph in the custom HR/contractor ingest to find the engagement end-date.

#Trigger Form to collect:

1. Role-based image needed (eng tools / design tools / GTM tools)

2. Country of access

3. Engagement duration (auto-fill from HR ingest if available)

#Request Approval from the requester's engagement owner.

On approval, provision the AVD:

1. #Custom Azure AVD Create Host Pool Assignment with image template and user UPN.

2. #Custom Entra Assign User to AVD App scoped to this user only.

3. #Custom Entra Set Conditional Access restricting sign-in to the engagement country.

Time-box the access:

1. schedule_action wake on the engagement end-date to call #custom Azure AVD

2. Remove Assignment and Entra Revoke AVD App Access.

#Send Direct Message to the requester with AVD connection URL, sign-in credentials, expiry date, support path.

#Send Channel Message to #it-contractor-access logging the provision.

#Leave Internal Note capturing image, country, end-date.

#Resolve Request.

Parse: action (create / archive / unarchive / change visibility / add members / remove members / rename / set manager), target channel name, member list, visibility setting.

Validate name against policy:

1. Channels must match ^(launch|project|incident|team|all|fun|help|wg)-[a-z0-9-]+$.

2. Length ≤ 80 chars.

3. If invalid → #Send Direct Message explaining the rule.

#Lookup Users on the requester.

Authorization check:

• Create → any employee.

• Archive / rename / change visibility → requester must be a channel manager (#Get Channel Managers) or IT admin.

• Private channel operations → require #Request Approval from a channel manager.

#Search Channels to check if the channel already exists.

Execute the action:

• Create → #Create Channel with parsed visibility. Then #Set Channel Manager to the requester. #Set Custom Retention to policy default.

• Add members → if a list, #Lookup Users to resolve, then #Add Users To Channel. If Okta group sync requested, #Get Group Members then #Add Users To Channel.

• Remove members → #Remove User From Channel for each.

• Archive → #Archive Channel.

• Unarchive → #Unarchive Channel.

• Change visibility → #Change Channel Visibility.

• Rename → #Rename Channel.

• Set manager → #Set Channel Manager.

If the request mentions pinning a doc: #Slack Pin Message action with the doc URL.

#Send Direct Message confirming the change with the channel link.

#Leave Internal Note capturing action, channel, members.

#Resolve Request.

Query the custom Productiv ingest via #Search Graph for seats with no logins in 60+ days across Outreach, Gong, Lattice, Figma.

For each stale seat:

• #Lookup Users on the seat owner with includeManager and includeSlackId.

• Skip if user was hired in the last 30 days (grace period) or has an active PTO/leave entry in HR ingest.

#Send Direct Message to the user (cc manager in a separate DM): "You haven't logged into {{app}} in 60 days. Still need it? Confirm in 7 days or it gets reclaimed." with a #Trigger Form containing "Keep" / "Reclaim".

schedule_action wake 7 days later to check the form response.

On wake, branch on response:

• Keep → log to internal note, #Send Direct Message confirming, no further action.

• Reclaim or no response → execute reclamation:

  • For Okta-managed app → #Remove from Group for the entitlement group.

  • For app with native API → call the custom {{App}} Remove Seat action.

#Send Direct Message to the user confirming reclamation with re-request instructions if needed.

#Send Channel Message to #it-licenses with: user, app, seat reclaimed, savings estimate.

#Create Linear Issue weekly summarizing total seats reclaimed and dollar savings.

Pull spend:

• #Custom Ramp List Transactions for last 30 days.

• #Custom NetSuite Get Spend by Cost Center.

Compute baselines per employee / cost center / vendor / category.

Detect anomalies:

• Spike: today >3x trailing AND >$500.

• New vendor: first transaction AND >$10k.

• Unusual category: cost center with no history AND >$1k.

• Late-night: card swipes midnight-5am local.

• High-velocity: >10 transactions on same card in 1h.

• Round-number suspicious: round numbers >$5k.

For each flagged transaction:

• #Custom Get Transaction Owner (cardholder).

• #Lookup Users with includeManager.

• #Custom Get Cost Center Owner.

Routing:

• High confidence (multiple signals): #Send Channel Message to #finance-anomaly + DM to cost-center owner + cardholder + finance lead.

• Medium: DM cost-center owner with #Trigger Form for clarification.

• Low: log for weekly batch.

Potential fraud (late-night + high-velocity + round + new vendor):

• #Custom Ramp Pause Card immediately.

• #Send Channel Message to #finance-fraud-log.

• DM cardholder.

• #Custom Page Finance Oncall.

schedule_action wake at 24h for responses.

Weekly summary to #finance with counts + resolution rate.

#Leave Internal Note per anomaly.

#Trigger Form to collect (pre-fill from parse where possible):

• Vulnerability ID (CVE / advisory) or description.

• Affected asset(s) / repo / service.

• Severity (or auto-pull from advisory).

• Source (scanner / manual / customer report).

• Business context / exposure.

#Lookup Users on the requester.

Dedup check:

• #Search Linear Issues for an open ticket referencing the same CVE + asset.

• If found → #Send Direct Message to requester with the existing ticket link ("already tracked"), add them as a subscriber, and #Resolve Request. Exit.

Enrich:

• #Web Research the CVE/advisory for CVSS, fix version, exploitability, known-exploited status.

• #Get Asset Owner for the affected asset(s). If owner can't be resolved → default route to #security for triage.

False-positive / not-applicable path:

• If the affected asset isn't actually running the vulnerable version (custom Verify Asset Version) → #Send Direct Message to requester noting not-applicable, #Leave Internal Note, and #Resolve Request. Exit.

Prioritize:

• Internet-facing + critical → P0; internal + critical → P1; high → P2; else P3.

#Leave Internal Note capturing the enriched assessment.

For P0/P1:

• #Send Channel Message to #security with the finding + owning team.

Route to the owner:

• #Create Linear Issue in the owning team's project with CVE detail, affected assets, fix, SLA (P0 24h / P1 7d / P2 30d).

• #Send Direct Message to the team lead with the issue link.

Track:

• schedule_action wakes at the SLA windows to check status (#Get Issue Status).

• Unresolved past SLA → #Send Channel Message escalating to #security-leads; for P0 also #Page Security Oncall.

On remediation (issue closed):

• #Verify Fix Deployed (re-scan the asset) to confirm the vuln is actually gone before closing.

• #Vanta Log Remediation for evidence.

• #Send Direct Message to the requester confirming.

#Resolve Request.

#List Devices (Kandji) with all enrolled devices.

For each device, #Get Device Details and #Get Device Parameters to pull telemetry.

Filter to devices matching any trigger condition.

For each matching device:

• #Lookup Users on device.assignedUserEmail to get the owner.

• Skip if the user is on PTO/leave (check HR ingest) or if the same device was already pinged in the last 7 days.

#Send Direct Message to the user: "Saw your laptop's been struggling — looks like {{issue summary}}. Want me to run the fix?" with #Trigger Form containing "Run fix" / "Schedule for later" / "Not now".

schedule_action wake at 24 hours to check the form response.

On wake, branch on response:

• Run fix → execute remediation:

  • Disk full → #Create Kandji Custom Script for cleanup (clear caches, purge old downloads).

  • OS outdated → #Create Kandji Custom Script to trigger software update.

  • Frequent crashes → #Kandji Blank Push (Force Check-In) then #Create Kandji Custom Script to reset problem services.

• Schedule for later → re-schedule wake for the chosen time.

• Not now or no response → proceed to step 8.

schedule_action wake at 48 hours after the fix to verify resolution via re-checking telemetry.

If still failing or user declined: #Create Linear Issue in the IT project assigned to a human technician.

#Send Direct Message to the user confirming the outcome.

#Leave Internal Note capturing the diagnosis and action.

#Lookup Users on the requester to identify the user.

#List Devices (Kandji) filtered by assignedUserEmail to find their device(s).

#Trigger Form to collect:

• Symptom (peripheral / display / audio / network / performance)

• When it started

• What they've already tried

#Get Device Details (Kandji) and #Get Device Parameters to pull current state.

#Kandji Get Device Library Items Status to confirm required drivers/profiles are installed.

#Search Knowledge Base for the symptom + device model for any known internal fixes.

If no KB hit: #Web Research vendor docs (apple.com, Microsoft Learn, Dell, Logitech) for the specific symptom.

Walk the user through fixes step-by-step via #Send Direct Message:

• For peripherals → reset / re-pair / reinstall driver

• For display → NVRAM reset, check cable, try alternate port

• For audio/video → reset Core Audio / Windows audio service via Kandji script

• For performance → free up RAM, check Activity Monitor / Task Manager

After each step, ask "did that fix it?" via #Send Direct Message.

If fixed → #Resolve Request.

If hardware-failure signature detected → kick off IT-15 RMA & Repair flow.

If still unresolved after exhausting steps → #Escalate Request to a human IT technician.

#Leave Internal Note capturing the diagnosis trail and resolution path.

#Lookup Users on the requester with includeManager.

#List Devices (Kandji) filtered by assignedUserEmail to find their device(s).

#Trigger Form to collect:

• Which device

• Where it was last seen

• When

• Whether it might be recoverable or is confirmed lost/stolen

• Whether they want a replacement

#Get Device Details to confirm device state.

Execute immediate containment in parallel:

• #Enable Lost Mode (Kandji) with a custom message and contact phone.

• #Play Lost Mode Sound (Kandji) to help recovery attempts.

• #Device Lock (Kandji) with a 6-digit PIN.

#Revoke All User Sessions (Okta) to invalidate any active sessions.

If the user indicated the device is confirmed stolen:

• #Custom Kandji Remote Wipe action with selective wipe.

• #Reset User Factors (Custom) to invalidate any device-bound factors.

#Create Linear Issue in the security project with severity High, including device serial, last-seen location, user, timestamp.

#Send Channel Message to #security with the incident summary and Linear link.

#Send Channel Message to #it-alerts with the device + user.

If replacement requested → trigger IT-14 New Device Order by creating a follow-up request.

#Send Direct Message to the requester with:

• Confirmation of containment actions taken

• Replacement order status (if applicable)

• Police report instructions (if stolen)

• Insurance claim instructions

schedule_action wake at 7 days to check if the device was recovered.

#Leave Internal Note capturing all actions and timestamps.

#Lookup Users on the requester.

#List Devices (Kandji) filtered by assignedUserEmail.

#Trigger Form to collect:

• Which device

• Symptom description

• Severity (can't work at all / partial use / cosmetic)

• Whether they need a loaner immediately

#Get Device Details to confirm device, serial number, purchase date, warranty status.

Determine RMA path based on vendor:

• Apple → #custom Apple Business RMA Create with serial and symptom.

• Dell/Lenovo → #custom Dell ProSupport RMA or Lenovo Warranty Service.

Capture the RMA case number and shipping label.

If user needs a loaner (severity = can't work):

• #Custom BlueTally Reserve Loaner with matching model.

• #Custom ComputerCare Ship Loaner with overnight shipping.

• Capture loaner tracking number.

#Send Direct Message to the user with RMA case, shipping label, loaner tracking, send-in instructions, expected turnaround.

schedule_action daily wake to:

• #Custom Get RMA Status.

• #Send Direct Message if status changed.

On repair completion + return:

• #Get Device Details to confirm repaired device is back online in Kandji.

• #Custom ComputerCare Return Loaner with return shipping label.

• #Send Direct Message with loaner return instructions.

#Leave Internal Note capturing RMA case, loaner ID, dates.

#Resolve Request after loaner return.

Pull all data sources in parallel:

• #List Devices (Kandji) for enrolled devices.

• #Custom Intune List Devices for Windows enrolled devices.

• #Custom Jira Assets Query for the asset register.

• #Search Graph for the HR roster from the HR ingest.

Build a unified view by serial number and assigned user.

Compute mismatches:

• Lost-not-recovered: marked lost in any system but still active elsewhere.

• Retired-but-active: marked retired in asset register but checking in to Kandji/Intune.

• Employee-without-device: active employee in HR but no device assigned.

• Device-without-owner: active device but unassigned or owner is offboarded.

• Owner-mismatch: different owner in Kandji vs Jira Assets.

For each mismatch:

• Determine the asset owner (IT team member responsible).

• #Send Direct Message to the asset owner with the mismatch, proposed fix, and a

• #Trigger Form to approve / modify / dismiss.

schedule_action wake at 7 days for each mismatch to check resolution.

On wake: if mismatch still exists, #Create Linear Issue for IT to resolve.

After full daily reconciliation:

• #Send Channel Message to #it-asset-ops with totals and trend.

Quarterly run also produces a Linear summary issue with trend data via #Run Query.

Parse the target cluster(s) + info type (health / utilization / alerts / specific workload).

#Lookup Users on the requester.

Permission check:

• #Check Cluster Visibility — requester allowed to see prod clusters?

• If requesting prod without permission → #Send Direct Message explaining, offer staging/non-prod view instead; do not expose prod data.

Resolve the cluster:

• #Datadog List Clusters.

• If $cluster not specified and multiple exist → #Send Direct Message with a #Trigger Form to pick one (or "all").

• If named cluster not found → #Send Direct Message with the available cluster list; #Resolve Request. Exit.

Query Datadog in parallel for the resolved cluster(s):

• #Datadog Get Cluster Health — node status, control-plane, pod phase counts.

• #Datadog Get Cluster Utilization — CPU/mem requests vs limits vs usage.

• #Datadog Get Active Monitors (triggered/warn/ok).

• #Datadog Query CrashLoop/Restarts if pod-health was asked.

• If a query returns no data / errors → mark that section "unavailable" rather than failing the whole response.

Format the response:

• Cluster summary: nodes healthy/total, pods running/pending/failed, top utilization, active alerts.

• Highlight anything abnormal (crashloops, node pressure, firing monitors).

#Send Direct Message with the formatted snapshot + Datadog dashboard link.

Offer follow-ups: drill into a namespace / page the on-call / open a ticket.

#Leave Internal Note.

#Resolve Request.

#Lookup Users on the requester.

#List Devices (Kandji) to get OS version and model.

#Trigger Form to collect:

• Application or service

• Exact error message

• When it started

• What they've tried

#Search Knowledge Base first for the symptom + application.

If no KB hit or stale: #Web Research with a focused query like {{app}} {{error}} {{os_version}} targeting vendor docs.

Synthesize the top fixes from web + KB into 3–5 steps.

Walk the user through them in #Send Direct Message, asking "did that work?" after each.

If a Kandji-side fix is needed: #Create Kandji Custom Script or custom Kandji Reinstall Library Item.

On resolution → #Resolve Request and offer to save the fix back into a new KB article.

If unresolved → #Escalate Request with the full diagnostic trail in #Leave Internal Note.

On trigger, identify the affected service from the alert payload.

#Web Research the vendor's status page to confirm and get expected resolution time.

If unconfirmed → wait 5 minutes and re-check; do not alert on noise.

On confirmation:

• #Send Channel Message to #it-status with: service, scope, vendor status page link, expected resolution.

• #Send Channel Message to #all-company with a brief user-facing message.

#Search Requests for open requests in the last 2 hours mentioning the affected service.

For each matching request:

• #Leave Internal Note tagging it as related to the outage.

• Update the category to outage-{{service}} via custom action.

• #Send Direct Message to the requester: "This looks related to an active {{service}} outage. We'll update you when resolved."

schedule_action wake every 15 minutes to:

• Re-check the status page.

• #Send Channel Message updates to #it-status on changes.

On confirmed resolution:

• #Send Channel Message to #it-status and #all-company with the all-clear.

• For each tagged request, #Send Direct Message to the requester asking if their issue resolved.

• #Resolve Request for any request the user confirms is fixed.

#Create Linear Issue post-outage for a retro doc with duration, impact, tagged-request count.

#Lookup Users on the requester with includeGroups and includeManager.

Determine VIP status — requester is VIP if any of:

• In the vip Okta group (execs, board).

• Title matches ^(CEO|CFO|CTO|COO|VP|SVP|Chief).

• In active on-call rotation via #Get PagerDuty Oncall Users.

• In customer-facing-active group (CSMs in an active meeting).

If not VIP → exit without modification (let normal routing apply).

If VIP:

• #Escalate Request with priority URGENT and a sub-15-minute SLA tag.

• #Custom PagerDuty Page to the IT on-call engineer and backup.

• #Reroute Request to a private VIP-only channel.

• #Send Channel Message to #it-vip with the request link, requester title, underlying ask.

• #Assign User to the request (the IT on-call engineer).

#Send Direct Message to the requester acknowledging fast-track and giving them the on-call engineer's name + ETA.

#Leave Internal Note capturing VIP determination reason and on-call assignment.

Continue handling the underlying request — do NOT resolve here; the on-call engineer takes over.

Parse start date, end date, leave type (PTO / sick / bereavement / jury / personal), and reason if provided.

#Lookup Users on the requester with includeManager.

#Custom Workday Get PTO Balance (or HiBob/UKG equivalent) for the requester, broken down by leave bucket.

Validate the request:

• Sufficient balance for PTO? If not, #Send Direct Message with the shortfall and ask to adjust dates or take unpaid.

• Within blackout dates (#custom Workday Check Blackout Dates action)? If yes, surface the conflict and ask the user to choose a new date.

• Overlap with team's max-out-at-once threshold? #Custom Workday Get Team PTO Calendar action. If exceeded, flag for manager.

Branch on leave type:

• PTO / personal → #Request Approval from manager.

• Sick (≤3 days) → auto-approve, no approval needed.

• Sick (>3 days) → auto-approve but custom Workday Trigger STD Eligibility Check.

• Bereavement → auto-approve up to policy limit (e.g. 5 days); over that, manager approval.

• Jury duty → auto-approve with proof-of-summons upload via #Trigger Form.

On approval:

• #Custom Workday Submit Time Off with the dates and type.

• #Custom Google Calendar Block Time on the requester's calendar with the leave label.

• #Custom Slack Set Status to "On PTO" for the leave window.

• #Out Of Office to set an auto-reply for the leave window (offer to compose; user can edit).

#Send Direct Message to the requester confirming with dates, remaining balance, and out-of-office status.

#Send Direct Message to the manager confirming the approved leave so they can plan coverage.

If leave is >5 consecutive days, schedule_action wake 2 days before the user returns to send a "welcome back" prep with their unread Slack threads and the team's status updates.

#Leave Internal Note capturing dates, type, approval path, balance impact.

#Resolve Request.