FS-DOC-03Operations
Process Runbook / SOP
Password Reset & Access Requests
[YourCompany.com] · IT Department · Prepared by FullSpec · [Today's Date]
This runbook covers how the Password Reset and Access Requests automation works day to day, what your team needs to do, how to handle situations that fall outside the normal flow, and how to keep the system running well over time. Almost everything in this process runs automatically. Your team's only regular responsibility is reviewing escalated cases where a manager has denied a request or an identity challenge has failed. Keep this document somewhere your IT team can find it quickly.
01Process overview
When a staff member gets locked out of an account or needs access to a new system, they submit a request through a Slack slash command or a web intake form. From that point, three automation agents handle intake and classification, identity verification or manager approval, and access provisioning across Okta and Google Workspace, all without IT needing to touch the request unless it is flagged as an exception. Every action is logged in Jira automatically, giving your team a complete audit trail for every request handled.
Process name
Password Reset & Access Requests
Trigger
A staff member submits a password reset or access request via a Slack slash command or the web intake form
Final output
Access granted or password reset confirmed, requester notified via Slack, and Jira ticket closed with a full audit log entry
Agents running
Request Intake Agent, Verification and Approval Agent, Provisioning and Audit Agent
Tools involved
Slack, Jira, Okta, Microsoft Azure AD, Google Workspace, automation platform
Weekly volume
Approximately 15 requests/week (around 60/month)
Human checkpoint
IT escalation review when a manager denies a request or an identity challenge fails
Process owner
IT Support Lead
02Step-by-step: what happens and who acts
What you actually need to do: In the entire automated flow, your team has one active responsibility. When a request is escalated because a manager has denied access or an identity challenge has failed, you will receive a Slack alert directing you to the flagged Jira ticket. You review the situation, make a judgment call, and take whatever action is appropriate in Okta or Google Workspace. Every other step runs without you.
Step
What happens
Who acts
Type
1
A staff member submits a password reset or access request using the Slack slash command or the web intake form. The automation platform receives the structured input immediately.
Staff member
Human
2
The Request Intake Agent classifies the request as either a password reset or a new access request, extracts the requester details and system information, and creates a fully populated Jira ticket in seconds. No manual data entry is needed.
Request Intake Agent
Automated
3
For password resets, the Verification and Approval Agent triggers an Okta identity challenge sent to the requester's registered device or secondary email. For new access requests, it sends the requester's manager a structured Slack message with one-click approve or deny buttons.
Verification and Approval Agent
Automated
4
If the manager does not respond within two hours, the agent sends an automatic reminder via Slack. If the identity challenge is completed or the manager approves, the process moves forward. If the manager denies the request or the identity challenge fails, the ticket is flagged and routed to the IT escalation queue.
Verification and Approval Agent
Automated
5
IT reviews the escalated Jira ticket, assesses the situation, and takes the appropriate action manually in Okta or Google Workspace. This is the only step that requires human judgment.
IT Support
Human
6
Once verification passes or approval is received, the Provisioning and Audit Agent calls the Okta API to perform the password reset or assign the approved access role. This happens immediately without any IT involvement.
Provisioning and Audit Agent
Automated
7
If the request involves Google Workspace, the Provisioning and Audit Agent calls the Google Workspace Admin API in the same run to add the user to the correct group or shared drive.
Provisioning and Audit Agent
Automated
8
The Provisioning and Audit Agent sends the requester a formatted Slack message confirming what access they now have and any next steps, such as setting a new password on first login.
Provisioning and Audit Agent
Automated
9
The Provisioning and Audit Agent updates the Jira ticket with a full audit note recording the action taken and the approval method used, then marks the ticket as resolved. The record is immediately available for compliance review.
Provisioning and Audit Agent
Automated
Process Runbook / SOPPage 1 of 3
FS-DOC-03Operations
03Handling exceptions
The automation is designed to handle the vast majority of requests without any IT involvement. The scenarios below cover the situations that fall outside the normal flow, what the system does in each case, and what your team needs to do.
Situation
What the system does
What you do
A request arrives with missing or incomplete information (for example, no system name provided for a new access request)
The Request Intake Agent detects that required fields are missing and sends the requester an automated Slack message listing what information is needed. The Jira ticket is created in a pending state and is not progressed until the information is supplied.
No action needed unless the requester comes to you directly. If they do, direct them to reply to the automated Slack message with the missing details.
A duplicate request is submitted (the same staff member submits the same request more than once within a short window)
The automation detects a duplicate based on requester identity and request type, suppresses the second ticket, and sends the requester a Slack message confirming their original request is already being processed.
No action needed. If a duplicate ticket does appear in Jira despite the check, close it manually and add a note marking it as a duplicate.
An identity challenge fails (the requester cannot pass the Okta verification step)
The Verification and Approval Agent records the failed attempt, flags the Jira ticket with a failed verification status, and routes it to the IT escalation queue. The requester receives a Slack message advising that their request needs manual review.
Review the flagged Jira ticket. Verify the requester's identity through an alternative method (for example, a video call or a manager confirmation), then action the reset manually in Okta if satisfied.
A manager does not respond to the approval request after two reminder messages
After the first reminder at two hours and a second at four hours with no response, the automation flags the Jira ticket as approval timed out and routes it to the IT escalation queue. The requester receives a Slack message advising of the delay.
Review the Jira ticket. Contact the manager directly to get a decision. Once you have a response, action or close the request accordingly and update the ticket with a note.
A manager denies an access request
The Verification and Approval Agent records the denial in the Jira ticket, notifies the requester via Slack that their request has not been approved, and closes the ticket with a denied status. No access change is made.
No action is required unless the requester escalates to you to dispute the decision. In that case, handle the conversation with the manager directly and re-open the ticket if the decision changes.
Okta or Google Workspace is unavailable when the provisioning step runs (tool outage or API error)
The Provisioning and Audit Agent logs the failure against the Jira ticket, sets the ticket to a provisioning failed status, and sends an alert to the IT escalation queue via Slack. The agent retries automatically up to three times with a five-minute gap between attempts before escalating.
If the retries do not succeed within the retry window, log into Okta or Google Workspace directly and complete the provisioning step manually. Update the Jira ticket with a note confirming what was done and when.
Process Runbook / SOPPage 2 of 3
FS-DOC-03Operations
04Who to contact and when
Fill in the rows below once your team is confirmed. The FullSpec rows are fixed. Refer to this table whenever you need to escalate a technical issue, report unexpected behaviour, or notify the right person of a policy change that affects the automation.
Role
Name
How to reach them
Process owner (IT Support Lead)
Priya Nair
[Rep email]
Approvals escalation (Operations Manager)
James Okafor
[Rep email]
Okta admin (service account owner)
[Your name]
[Rep email]
Google Workspace admin
[Your name]
[Rep email]
Jira project administrator
[Your name]
[Rep email]
FullSpec builder
Siobhan Reilly
support@gofullspec.com
FullSpec support
FullSpec Support Team
support@gofullspec.com
For any unexpected automation behaviour, provisioning failures that persist after manual retry, or changes to your Okta or Google Workspace configuration that may affect the build, contact the FullSpec team at support@gofullspec.com before making changes to the automation platform workflows directly.
05Ongoing maintenance
The automation runs without daily oversight, but a small number of routine checks will keep it performing reliably. The table below sets out what to check, when, and who is responsible.
As needed (when a new system is added to your stack)
Update the request intake form and Slack command options to include the new system name. If the system requires a new Okta role or a new Google Workspace group, ensure those are created before the intake update goes live. Notify FullSpec if the provisioning logic needs to be extended.
IT Support Lead, with FullSpec support if provisioning changes are needed
As needed (when messaging or confirmation wording needs updating)
Update the Slack message templates used for manager approval requests, requester confirmations, and escalation alerts. These are managed in the automation platform workflow configuration. Contact FullSpec to make changes if you are not comfortable editing the workflow directly.
IT Support Lead or FullSpec
Monthly spot-check
Pick three to five recently closed Jira tickets at random and confirm that each one has a complete audit log entry, the correct approval method recorded, and a matching Slack confirmation sent to the requester. Flag any gaps to FullSpec.
IT Support Lead
Weekly (every Monday morning)
Review the Jira escalation queue for any tickets left in a pending, failed, or timed-out state from the previous week. Clear any outstanding escalations and confirm that the error log in the automation platform shows no recurring failure patterns.
IT Support Lead
As needed (when a staff member joins, leaves, or changes role)
Update the manager reporting-line data in Okta and Microsoft Azure AD to ensure approval messages route to the correct person. If a new IT team member takes over as process owner, update the contact table in this document and notify FullSpec to update the escalation alert routing.
IT Support Lead and Okta admin
Quarterly review
Compare the current monthly request volume against the baseline of approximately 60 requests per month. If volume has grown significantly, review whether the automation platform's concurrent run limits and Okta API rate limits are still appropriate. Share the volume figures with FullSpec so any capacity adjustments can be planned.
Operations Manager and FullSpec
The single most common maintenance issue for this process is stale reporting-line data in Okta or Microsoft Azure AD. If the directory is not kept up to date when people change managers or move teams, manager approval messages will go to the wrong person, causing delays and manual fixes. Make updating the directory part of your standard offboarding and role-change process to avoid this.
Process Runbook / SOPPage 3 of 3