Run your quarterly access review without the spreadsheet

I want an app that my IT and compliance team opens each quarter to run our shared credential access review, instead of the usual ritual of exporting to a spreadsheet and chasing managers over email. User access reviews are a required SOC 2 control (Common Criteria CC6.1, CC6.2, and CC6.3), and today we rebuild the same evidence pack by hand every three months. This app is the review surface itself: two or three people sit in it, work down a list, make a call on each row, and finish with the auditor evidence already written.

The main screen is a review board with one row per person per shared vault. Build it from the 1Password Events API, which means the connected 1Password credential has to use an Events API base URL (events.1password.com, or the events.ent.1password.com, events.1password.ca, and events.1password.eu regional variants) together with an Events Reporting bearer token that covers item usage and audit events. A Connect server token will not authenticate against these reads, so validate the base URL shape on connect and say so plainly if someone pastes a Connect URL. This requires 1Password Business or Enterprise.

Here is the constraint that shapes the whole app: 1Password exposes no vault membership endpoint and no group membership endpoint, so there is no members list to read. Derive the access picture instead. Use 1Password List Item Usages to learn who actually opened which item in which vault and when they last did it, and use 1Password List Audit Events to learn who was granted or removed from a vault and by whom. Group those two streams by person and vault to produce the board rows. Each row should carry the person, the vault, how many distinct credentials in that vault they touched, the date they last opened anything in it, and whether the audit stream shows a grant or a removal for them inside the window. Default the review window to the last 90 days, with a date range control so I can widen it. Make it obvious in the UI that the board is derived from observed access rather than a permissions export, because a reviewer needs to understand what they are signing off on.

Enrich every row with BambooHR Get Employee Directory. Match on email address, and show the person's department, their manager, and whether they are still employed. Do not drop a person who fails to match the directory. Show them with an unmatched marker instead, since contractors, service accounts, and shared logins land there and those are exactly the rows a reviewer should look at hardest. Fetch the directory once per campaign and reuse it across rows rather than looking each person up individually.

Sort the board so the risky rows come to the reviewer rather than the other way round. Anyone who is no longer active in BambooHR floats to the top, followed by anyone who has not touched a credential in that vault in 60 days, followed by anyone who could not be matched to the HR directory at all. Everything else sorts underneath by last access date, most recent last. Show the reason a row was floated as a short badge on the row, and let me filter the board down to just the flagged rows, just one vault, or just one department. The last access date is the single column reviewers lean on most, so give it real prominence and show both the date and a plain relative reading like 74 days ago.

Every row has three buttons: Keep, Revoke, and Rotate. Clicking one records the decision along with the name of the signed in reviewer and the timestamp, and persists it server side so the campaign survives closing the tab and can be picked up by a second reviewer later. Let a decision be changed before the campaign is finished, keeping the latest reviewer and timestamp. Let the reviewer attach a short note to any row, because the justification is often the thing the auditor actually reads. Show live campaign progress somewhere permanent, for example 61 of 84 rows decided, so two people working the board at once can see where they are.

Revoke and Rotate each file a Jira ticket through Jira Create Issue, assigned to IT. Prefill the summary with the person, the vault, and the action required, and put the supporting detail in the description: the last access date, the number of credentials touched, their department and manager from BambooHR, their employment status, the reviewer who made the call, and any note they left. Let me set the Jira project, issue type, and assignee in app settings once rather than per ticket. Write the returned issue key back onto the row and display it, so nobody files a duplicate for the same person and vault. Keep decisions no ticket.

A Finish campaign button closes the review out. It creates a dated spreadsheet with Google Sheets Create Spreadsheet, named for the review period, then writes the full decision log into it with Google Sheets Append Values: one row per reviewed person and vault, carrying the person, their email, department, manager, employment status, the vault, credentials touched, last access date, days since last access, the decision, the reviewer name, the decision timestamp, any note, and the Jira issue key where one was raised. Put a header row in first so the sheet reads as evidence rather than a data dump. Then post a completion summary to our security channel with Slack Bot Send a Message: the campaign name and window, how many rows were reviewed, the split of Keep, Revoke, and Rotate, how many people were flagged as inactive or no longer employed, how many tickets were raised, and a link to the spreadsheet. Block finishing while rows are still undecided, and tell me which ones are outstanding.

Handle the Events API paging properly. Both List Item Usages and List Audit Events are cursor based POST reads that change no state. Send a reset cursor request carrying the campaign window on the first call, use a page size of 100 (the valid range is 1 to 1000), then replay the returned cursor while the response reports there is more to read. The cursor is a durable checkpoint that stays valid across sessions, so persist it per campaign on the server and resume from it instead of refetching the whole history every time the app opens. Stay under the ceiling of 600 requests per minute and back off when a rate limit response comes back. Assembling a 90 day window takes a while, so build the board behind a visible progress indicator rather than a blank screen.

Two smaller things. Vault identifiers in the events stream are opaque 26 character strings, so if a 1Password Connect credential is also connected, resolve friendly vault names with 1Password List Vaults and credential titles with 1Password List Items. If only the Events credential is connected, fall back to showing the identifier and say why, rather than failing. And keep finished campaigns around in a history view, so I can open last quarter's board read only, see every decision and who made it, and reopen its evidence spreadsheet without digging through Drive.