#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

#Lookup Users on $employee.email with includeGroups, includeApps, includeManager.

#Search Okta User by Email, then #Revoke All User Sessions, then #Deactivate User (Okta).

#Suspend Google User and #Transfer Drive Files to $employee.managerEmail.

#Out Of Office to set the auto-reply.

If department == "Engineering": #Remove User from Org (GitHub), #Disable Datadog User, custom AWS IAM detach.

If department == "Sales": revoke Salesforce/Gong/Outreach seats (custom actions).

Loop user's apps from step 1; for each Productiv-tracked SaaS, call the appropriate #Remove from Group action.

#Kandji: Force Device Check-In then #Device Lock for each assigned device.

#Update User (Ramp) to suspend the card.

Create Linear Issue in the IT-Audit project documenting the offboarding.

#Send Channel Message to #it-audit summarizing what was revoked.

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