Automate IT Access Requests and Approvals in Google Workspace
Access request automation handles what happens after someone asks for access: resolving the requester's context, applying the policy that fits, routing approvals to the right people, executing the change across Google Workspace and connected systems, and recording the decision. It works alongside directory sync, which grants standard access at account creation, and alongside the rest of your IT operations automation.
When access depends on site, business entity, department, role, and who owns the resource, one request turns into ten decisions. A ticket records the request. Something still has to make the decisions and do the work.
One Request, Ten Decisions
A manager sends four words to IT: "Give this employee access to the regional operations Drive." It looks like one action. Before anyone can act on it, someone has to establish all of the following.
- Is the employee active, and on what contract type?
- Which business unit or legal entity do they belong to?
- Which site or region?
- Who is their current manager?
- Who owns the Drive being requested?
- Does the owner's entity require its own approval?
- Which approver applies to this combination?
- Viewer, contributor, or manager access?
- Is this permanent, or should it expire?
- Does a data or security policy add a second gate?
With one site, one entity, and one policy, most of those answers are constants and a template handles the request. Add locations, entities, contract types, and resource owners who don't report to IT, and every answer becomes a lookup — on every request, several times a day.
Why This Work Stays Manual
Most organizations already own tools that touch access requests, and each is doing the job it was designed for. Requests still land in an inbox because the work sits between them.
| Layer | What it is designed to do | What sits outside its design scope |
|---|---|---|
| Identity IdP, GCDS, directory sync |
Establish who someone is and grant the standard entitlements that come with their role, at account creation. | Requests that are not standard, and the approvals and conditional logic that decide them. |
| Request service desk, ITSM, ticketing |
Capture the request, route it to a queue, hold the SLA, and keep the record. This is your system of record and it stays that way. | Performing the change across Drive, Groups, delegation, licenses, and third-party applications. |
| Execution workflow automation |
Resolve context, apply policy, route approvals, execute across systems, log the decision, and expire the access. | Deciding what your policy should be. The process still has to be designed before it can be automated. |
What An Automated Access Request Looks Like End To End
Eight steps, in order. The same pattern covers a Shared Drive request, a Google Group membership, a license, or a transfer between sites — only the lookups and the policy change.
Request
Structured intake from a Google Form, Google Chat, email, or an existing ticket queue. Replaces a free-text message with half the details missing.
Context lookup
Directory attributes, reporting line, site, entity, contract type, and resource ownership are read automatically. Replaces opening the Admin console, the org chart, and a policy sheet.
Policy check
Rules decide which approval path applies to this requester, this resource, and this access level. Replaces remembering which entity needs a second sign-off.
Approval routing
Sequential, parallel, or conditional approvals, with delegation and escalation when an approver is unavailable. Replaces chasing two people who are both on leave.
Provisioning
The change executes across Google Workspace and connected systems — Drive, Groups, delegation, licenses, third-party applications. This is the part a ticket cannot do for you.
Confirmation
The requester, the manager, and the ticket are all told what was granted and until when. Replaces "did that ever get done?" three days later.
Audit log
Who asked, who approved, on what basis, what executed, and when — as one queryable record. Replaces reconstructing a decision from an email thread.
Review or expiry
Time-limited access is removed on its end date. Standing access is re-confirmed on a review cycle. Replaces permissions accumulating until offboarding or an audit.
What The Workflow Has To Know To Be Useful
Connecting two apps and passing a field between them is not the hard part of this problem. These six capabilities decide whether an access-request workflow survives a complex organization — worth using as a checklist against any tool, including this one.
Context lookup across more than one source
The answer to "who approves this" usually lives in several places at once: Google Directory for reporting line and site, an HR system for status and contract type, a policy sheet for entity rules, and the resource itself for its owner. A workflow that can only read one of those will always need a human to supply the rest.
Policy logic that branches on organizational attributes
The same request type has to resolve differently depending on site, entity, department, role, and access level. This is the capability standard templates lack, and the reason so many teams end up back in Apps Script — a template assumes one policy, and these organizations have several that overlap.
Conditional and multi-party approvals
Sequential chains, parallel approvals where a manager and a resource owner must both agree, a conditional second gate that only opens for sensitive resources, and delegation or escalation when an approver does not respond within the SLA.
Access with an expiry date attached to the grant
Temporary access should carry its end date from the moment it is approved, and removal should happen without anyone remembering to do it. Where expiry depends on a person noticing, permissions accumulate — and the accumulation is only discovered at offboarding or during a review.
Execution across several systems, with a defined failure path
One request often means a Drive permission, a Group membership, a license assignment, an asset register entry, and a ticket update. What happens when step four fails matters as much as the happy path: the workflow should retry, roll back, or escalate rather than leaving the request half-applied and silent.
An audit record that answers the question an auditor asks
Not a log of API calls, but a record of the decision: what was requested, which policy applied, who approved it and on what basis, what was executed, and when it expired. That record is also what makes an access review a query rather than a project.
Requests IT Teams Automate First
Grouped by the kind of decision involved rather than by product area, because the routing logic is what they share.
Access and entitlements
Self-service access requests, Google Group membership, Shared Drive permissions, Gmail delegation, elevated or temporary access, and license requests — each routed on the requester's site, entity, and role.
Conditional access approvals →Lifecycle and organizational change
Employee transfers between sites or entities, role changes, location changes, equipment and application requests, and new-site setup — where access has to be added and removed in the same transaction.
Onboarding & offboarding →Service delivery operations
Routing requests to the right queue across locations and business units, escalation and SLA handling when an approver does not respond, and bulk changes applied per site — Gmail signatures across forty branches, for example.
Bring us a request →Governance and review
Scheduled access reviews with owner sign-off, automatic revocation of expired grants, and security policy remediation when a permission drifts from policy.
Talk to us about controls & audits →Where Requests Come In, And Where The Record Lives
These are two separate decisions, and treating them as one is what makes automation projects look bigger than they are. Requests can arrive anywhere. The record can stay exactly where it is today.
Google Form
Structured intake. Triggers the workflow directly — no ticket required to begin.
Google Chat
Submit a request, ask about status, or approve, in the place people already work.
For the requests that will keep arriving by email whatever IT would prefer.
An existing ticket
Where the request type already has an established queue and SLA.
The entry point is a convenience decision. Routing, approval, execution, and audit behavior is identical regardless of which channel the request arrived through.
Controls live here rather than in the channel. That is why a Form submission and a ticket produce the same behavior and the same record.
Where a service desk exists, the workflow creates or updates the ticket and writes approvers, execution status, and audit detail back to it. Your ITSM remains the system of record. Where none covers this request type, the workflow's own audit history is the record.
The combination worth noticing: a request submitted through a Google Form can still produce a properly recorded ticket, because the workflow creates it. Convenient intake does not have to cost you service management discipline.
Requests and approvals in Google Chat
The same workflow can be published to Google Chat, using enterprise AI agents for Google Chat builder so a manager submits a request, asks where it stands, or approves one without leaving the conversation. Where a step needs interpretation rather than a rule — classifying a free-text request, for instance — an AI step can handle it, with the provider chosen centrally from Gemini, OpenAI, or Claude and the system instruction set once rather than per workflow. The approval gates, execution, and audit trail are the same ones described above. The conversational surface is an interface choice; the controls stay in the process.
Three Structures That Turn Simple Requests Into Conditional Ones
Most organizations running into this recognize themselves in one of three shapes. Many are two at once.
Multiple locations
Approval and access depend on branch, region, or site. The same job title carries different entitlements in different places, and the approver is usually local while IT is central. Common in retail, hospitality, restaurants, warehousing, logistics, home care, and construction.
Complex organizational structure
Approval depends on department, subsidiary, legal entity, reporting line, or who owns the resource. Several domains or brands may sit under one tenant, often the result of acquisitions, and each brought its own policy with it.
Distributed service delivery
A central IT team supports many semi-independent business units, each with its own habits and its own preferred way of asking. The volume is manageable; the inconsistency is what consumes the team.
Gordon Food Service Automated The Requests That Arrived Most Often
A distributed food distribution business with lean central IT and a high recurring volume of access and lifecycle requests across its sites. The IT team automated the request types that arrived most often — without Apps Script, and without replacing their existing tooling.
How the 83% was measured
Scoped to the request types brought into the workflow
Built without Apps Script
No custom code to maintain and no single owner to lose
Which requests they started with
The full sequence, in order, with the approval logic behind each
Get the Gordon Food Service case study
By submitting this form, you agree to Zenphi's privacy policy.
On The Edge Cases, Specifically
"Zenphi supports our IT operations, including user lifecycle management, very efficiently. We value its flexibility and adaptability to our needs. As long as you know what you want, you can create any workflow that suits your needs."
"The workflows we built with Zenphi to automate IT requests and approvals allowed us to reduce IT tickets by 83%. We used to handle most of these processes manually, because automating them with Apps Script required too much time."
"Zenphi simplifies Google Workspace user lifecycle management tasks effortlessly. With its help, I successfully automated our new hire process, ensuring smooth communication and data management throughout the onboarding journey."
Access Request Automation — Frequently Asked Questions
The questions IT teams ask before they start.
How is this different from what our IdP or directory sync already does?
Directory sync resolves identity and grants the standard entitlements attached to a role when the account is created. It is designed for what is predictable at provisioning time.
Access requests that arrive afterward — a specific Shared Drive, a Group, Gmail delegation, a third-party application, elevated access for two weeks — depend on context and approval, which sits outside that design scope. Hybrid setups are common and supported: Microsoft Entra ID can remain the identity provider while the request and execution layer works in Google Workspace.
Do we need to replace our service desk or ITSM?
No. Your service desk stays the front door and the system of record.
Requests can be raised there as they are today, and the workflow executes the change in Google Workspace and writes approvers, execution status, and audit detail back to the ticket. The workflow can also create the ticket when a request arrived through a Form or Chat, so the record stays complete regardless of how someone asked.
Can requests be submitted and approved through Google Chat?
Yes. A workflow can be published to Google Chat so people submit requests, check status, and approve without opening another tool, and approvals can also be actioned in one click from Gmail. Where a step needs interpretation rather than a rule, an AI step can handle it — the provider is chosen centrally from Gemini, OpenAI, or Claude, and system instructions are set once and locked rather than configured per workflow. The approval, execution, and audit controls are identical to any other entry point.
Can approval routing depend on location, business entity, or department?
Yes, and this is usually the reason teams look for something beyond a template.
The workflow reads the requester's site, entity, department, contract type, and reporting line, plus the owner of the resource being requested, then applies the approval path that matches that combination. One request type can therefore resolve to a local manager in one region, a manager plus a data owner in another, and an additional policy gate for sensitive resources.
How is temporary access revoked?
The end date is captured when the request is approved and travels with the grant, so removal is scheduled rather than remembered. On the expiry date the workflow revokes the permission, notifies the requester and approver, and closes the audit record. Where access needs to continue, it is extended through a new approval instead of quietly persisting — which is what stops permissions accumulating between offboarding events and reviews.
What happens if one step in a multi-system request fails?
Each step has a defined failure path rather than a silent stop. Transient failures retry; a step that cannot complete escalates to IT with the request context attached, and where a partial grant would be a problem the preceding steps can be reversed. The audit record shows exactly which steps completed, so nobody has to work out whether a request was half-applied.
What audit record is produced for each request?
A single record per request covering who asked and for what, the context the workflow resolved, which policy path applied, who approved and when, what was executed across which systems, and the expiry or review outcome. Because it is captured as structured data rather than assembled from an email thread, access reviews become a query rather than a project.
How does this compare to building the same thing in Apps Script?
Apps Script can reach the same APIs, and a first version is often quick to write. What tends to become expensive is everything around it: conditional routing across entities gets hard to read, approvals need somewhere to hold state, expiry needs a scheduler, and the audit trail has to be built deliberately. Then someone has to own the code after its author moves on. The trade is real — a platform means less control over the internals, and the process still has to be designed either way.
Bring One Request That's Manual Today
Pick an access request your team handles by hand — the one with the awkward approval path — and we'll build it with you in 30 minutes. You keep the workflow either way.