User360
Identity visibility
Built a single employee view that reduces the need to search multiple administration portals during IAM and IT support work.
The problem
“Does this employee have an account, is it active, and what assets are assigned?” is one of the most common questions in IT operations — and answering it honestly can mean opening seven different administration portals.
Each of those systems also has its own idea of what a user looks like: some hide deactivated accounts from their normal lookup APIs, some key accounts on a different principal name than the work email, and some only reveal a deleted account through a recycle bin.
The approach
User360 turns that question into a single Slack command. The slash command posts to a Cloudflare Worker, which fans out to every connected system in parallel, normalizes what comes back into one small status vocabulary, and replaces the “checking…” acknowledgement with a unified report — including an explicit warning tile for any system that could not answer.
There is deliberately no separate backend: the Worker is the whole service. Each integration authenticates directly with its vendor API using credentials held in Worker environment bindings, so no secret ever appears in code.
My role — Sole builder: problem framing, information architecture, integration model and the Slack-command workflow.
How it works, step by step
One lookup, seven systems
The implemented request path — step through it, or select a node. Example identity is fictional.
01Ask once
An engineer types one Slack command — for example /tocapps user360 jane.doe@example.com — instead of opening seven admin consoles.
Select any node in the diagram to inspect it.
- Person
- Connected system
- This project
- Info
- Success
- Failed
- Skipped
Example output
The unified response — data model
🚨 Recover equipment — user is offboarded but still holds assets
- Google Workspace
- Suspended
- Slack
- Suspended (via SCIM)
- Microsoft 365
- Deleted — found in recycle bin
- Atlassian
- API unavailable
- AssetSonar
- 2 assets still assigned
- PagerDuty
- No account
- TestRail
- No account
Illustrative rendering of the response model with dummy values — not a screenshot and not a live lookup.
Architecture
Architecture
There is no separate backend: the Worker is the entire service, calling vendor APIs directly from the edge.
- Person
- Connected system
- This project
- Data at rest
- Person
- Connected system
- This project
- Data at rest
Google auth is a service-account JWT with domain-wide delegation signed via WebCrypto; Microsoft uses client-credentials; the rest use token or basic auth. Every credential is a Worker environment binding — none are hardcoded.
Key engineering decisions
- Identity status
- Account status
- Assigned assets
- Application presence
- Basic access state
- Slack command
Switch to the technical view for the engineering trade-offs behind these.
Challenges & limitations
- User360 is a cross-system visibility tool, not a source of truth. A missing or failed response never means the employee has no account — that is exactly why failures render as explicit warning tiles.
- Some directories cannot distinguish “never provisioned” from “suspended” through their APIs; those collapse into one state, and the code documents it as an accepted tradeoff.
- Only AssetSonar contributes asset detail; the other six systems report account status only.
- Each provider gets a 10-second budget. A slower API is reported as unavailable rather than holding the whole answer hostage.
What I learned
The hard part was not calling seven APIs — it was refusing to guess. A frozen four-state vocabulary, visible failure tiles and re-verified lookups keep the report honest precisely when a directory hides deactivated users or a vendor API times out.
Project status
All seven integrations are implemented and exercised through built-in diagnostic commands. Shown here fully sanitized: no company domains, tenant hosts, deployment identifiers or real identities.
- Origin
- Started as a Slack entry point for an internal IT-operations portal.
- Sprint 1
- Google Workspace and Slack lookups; parallel fan-out and the ack-then-respond pattern.
- Sprint 2
- Microsoft 365 (UPN mapping + recycle-bin check) and Atlassian.
- Sprint 3
- AssetSonar member/asset lookup with the offboarded-with-assets alarm; PagerDuty.
- Sprint 4
- TestRail — seven systems in one report.