#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.

#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 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.

#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.

#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.

#Trigger Form to collect:

1. Leave type (birth-mother / birth-partner / adoption / foster)

2. Expected leave start date (or birth/placement date)

3. Expected duration (auto-suggest based on policy + tenure)

4. Whether they'll use FMLA (US) / STD / company top-up

5. Manager email

6. Backup contact info during leave (personal email)

#Lookup Users on the requester with includeManager.

#Custom Workday Get Parental Leave Policy to surface entitlement based on tenure and location.

#Custom Workday Get PTO Balance to factor in any pre-leave PTO they want to use.

Generate paperwork:

• #Custom DocuSign Send FMLA Request with prefilled fields.

• #Custom DocuSign Send STD Application if applicable.

• #Custom DocuSign Send Parental Leave Plan company-specific form.

Coordinate manager handoff:

• #Send Direct Message to the manager with: leave dates, coverage planning checklist, hand-off doc template.

• #Custom Google Calendar Block Time on requester's calendar for the leave window.

• #Custom Slack Set Status to "On parental leave - back {{returnDate}}" for the leave window (scheduled).

Pre-leave check-in:

• schedule_action wake 14 days before leave start to #Send Direct Message to requester: "Two weeks until leave starts. Anything we still need to wrap up?"

During leave:

• #Custom Pause Slack Notifications during leave.

• #Custom Pause Lattice Activity for the user.

• #Out Of Office to set auto-reply for the leave window with the backup contact.

Return-from-leave 1:1:

• #Custom Google Calendar Create Event for a 60-min welcome-back 1:1 with manager on the return date.

• schedule_action wake 3 days before return to #Send Direct Message: "Coming back on {{date}} — anything we should prepare for you?"

Coordinate benefits:

• #Send Email with QLE benefits enrollment info (30-day window for adding dependents).

• #Custom Trigger Benefits QLE for adding the child to coverage.

#Send Direct Message to the requester confirming everything is set up.

#Leave Internal Note capturing dates, paperwork status, manager handoff confirmation.

#Resolve Request.

#Lookup Users on the requester to get location (for region-specific policies), department, and tenure.

#Search Knowledge Base with the user's question as the query.

For multi-region benefits content (parental leave, holidays, healthcare), filter to the requester's location. If multiple regions match, surface labeled variants.

#Expand Knowledge Base Article for the top hit if more depth is needed.

Compose the answer in #Send Direct Message:

• Direct answer first (e.g. "You accrue 1.66 PTO days per month.")

• Personalized context if available (e.g. "Based on your tenure, you're eligible for...").

• Quoted source paragraph from the KB.

• Source link to the policy doc.

Ask if the answer resolved their question via a follow-up message.

If user confirms → #Resolve Request.

If user has follow-up questions or the policy is ambiguous:

• For simple clarifications, loop back to step 2.

• For complex / personal cases, #Prompt for Handoff to the benefits coordinator or HRBP based on topic.

If no relevant KB hit at all:

• #Send Direct Message explaining the limitation and #Prompt for Handoff to HR.

#Leave Internal Note capturing the KB articles surfaced and resolution path.

Parse the update type from the request.

#Lookup Users on the requester.

#Trigger Form to collect the specific new values, depending on update type:

• Address → street, city, state, zip, country, effective date

• Emergency contact → name, relationship, phone, email

• Phone → new number

• Marital status → status, effective date, spouse info if adding to benefits

• Dependents → name, DOB, SSN (if applicable), relationship

Validate inputs:

• Address → custom Validate Address (USPS/Smarty) action.

• Phone → format check.

• SSN → format check (no Luhn-style validation; just digit count).

Write to HRIS via #custom Workday Update Worker (or HiBob/Rippling equivalent) with the new values.

Propagate downstream changes:

• Address change → #custom Workday Trigger Payroll Tax Recalc (state taxes may change). Also #Update Okta User Profile (Custom) with new address fields. Also #custom Update Badge System Address for office access.

• Emergency contact → no further sync needed beyond HRIS.

• Phone → #Update Okta User Profile (Custom) with the new phone. #Custom Update Slack Profile Phone.

• Marital status / dependents → #custom Trigger Benefits Qualifying Life Event to open a window for benefits enrollment changes; #Send Email with QLE enrollment instructions.

#Send Direct Message to the requester confirming what was updated, in which systems, and any downstream effects (e.g. "Your address change triggered a payroll tax recalc; you'll see this on your next paystub.").

If marital / dependents change: #Send Email with QLE benefits enrollment link and 30-day deadline.

#Leave Internal Note capturing fields changed and systems synced.

#Resolve Request.

#Trigger Form to collect:

• Employee being changed

• New role / title

• New manager

• New department / team

• Effective date

• Comp change (yes/no, new amount, new band)

• Justification

#Lookup Users on the affected employee with includeManager and includeGroups.

#Lookup Users on the requester (assume manager initiating) to validate authority.

#Lookup Users on the new manager to confirm valid Okta record.

Approval chain:

• #Request Approval from current manager (skip if they initiated).

• #Request Approval from new manager.

• #Request Approval from HRBP for the new department.

• If comp change: #Request Approval from finance.

On full approval, execute changes on effective date (use schedule_action if effective date is in the future):

• #Custom Workday Update Worker with new title, manager, department, comp band, 

• comp amount.

• #Update Okta User Department for the new department.

• #Custom Okta Update Manager to set the manager field.

• For each group the employee was in: if it's role-based, #Remove from Group; if it's tenure-based, keep. Re-add to the new role's groups via #Add to Group.

• #Update Usergroup (Slack) to add to the new team usergroup and remove from old.

• #Custom Update Access Policies for any policies where manager-is-approver — the new manager becomes approver going forward.

• For department-specific tooling: provision new (e.g. Sales tools if moving to Sales) and revoke old.

#Add Users To Channel for the new team's Slack channels; #Remove User From Channel for old team channels (with grace period of 30 days for handoff).

#Send Direct Message to the employee confirming all changes.

#Send Direct Message to both old and new managers explaining the transition.

#Send Channel Message to #org-changes announcing the move.

#Leave Internal Note capturing all changes and approval trail.

#Resolve Request.

#Trigger Form to collect:

1. Employee being adjusted

2. Adjustment type (merit / market / sign-on / retention / promotion)

3. Current comp (auto-fill from Workday)

4. Proposed new comp

5. Justification (free text)

6. Market data attachment (if market adjustment)

7. Effective date

#Lookup Users on the employee and the requesting manager.

#Custom Workday Get Comp Band for the employee's role and level to check if the proposed comp falls within band.

#Custom Workday Get Compa-Ratio to show current and proposed compa-ratio.

Validate request:

1. In-band → standard approval path.

2. Above band → require additional VP approval.

3. Outside policy window (e.g. off-cycle merit when only quarterly cycles allowed) → require HRBP exception approval.

Approval chain:

1. #Request Approval from manager's manager (skip-level).

2. #Request Approval from HRBP with justification + market data attached.

3. #Request Approval from finance with budget impact calculation.

4. If above band → #Request Approval from the VP/Chief.

On full approval, on effective date:

1. #Custom Workday Submit Comp Change with new comp, type, effective date.

2. #Custom Workday Trigger Payroll Update for next pay cycle.

3. If sign-on or retention bonus, custom Workday Schedule Bonus Payment.

#Send Direct Message to the employee with a comp letter or update notification — composed from a template.

#Send Direct Message to the manager confirming the change and the next paystub the employee will see.

#Send Channel Message to #hrbp-comp for tracking.

#Leave Internal Note capturing approval trail, justification, market data.

#Resolve Request

#Trigger Form to collect:

• Purpose (mortgage / rental / visa / loan / other)

• Verifying party name, email, fax

• What to include (employment only / employment + salary / employment + salary + bonus)

• Any specific format required by the verifier

• Delivery preference (email to verifier directly, or email to requester)

#Lookup Users on the requester.

#Custom Workday Get Employment Data to pull: hire date, current title, current comp, employment status (FT/PT), location, manager.

If the request includes bonus / commission detail, #custom Workday Get YTD Compensation for the relevant breakdown.

Generate the letter:

• #Custom Generate Verification Letter From Template action picks the right template based on purpose (mortgage / visa / rental).

• Merge the Workday data into the template.

Route for signature:

• #Custom DocuSign Send to HR Signer with the company's authorized signer (HRBP).

• schedule_action wake at 24h; if unsigned, #Send Direct Message reminder to the signer.

On signature:

• If delivery is "to verifier" → #custom Send Letter to Verifier action (email or fax based on form input).

• If delivery is "to requester" → #Send Email to $requester.email with the signed letter attached.

#Send Direct Message to the requester confirming delivery method, date sent, and verifier contact.

#Leave Internal Note capturing purpose, verifier, data included, delivery confirmation.

#Resolve Request.