LifeCycleOne
Identity operations platform
Built an employee-lifecycle platform that centralizes onboarding, offboarding, identity visibility and operational workflows across enterprise SaaS systems.
The problem
Employee lifecycle work rarely lives in one system. A single new joiner may need a Google Workspace account with the right licenses and groups, a Microsoft 365 identity, Slack, Atlassian access and an asset record — and an offboarding may require all of it undone, across systems owned by different teams.
The hard part is not performing each action; every admin console can do that. It is knowing, afterwards, which steps succeeded, which failed, which were skipped on purpose — and what still needs a human.
The approach
LifeCycleOne is a centralized identity-operations portal built on Google Apps Script with Google Sheets as its datastore. Every lifecycle request becomes a job with one row per target application, executed through a registry of connectors that all speak the same result contract.
That per-application record is the core idea: a job never collapses into pass/fail. It finishes as Completed, Completed with Errors, or Partially Completed — and any single failed application can be retried on its own, with the full history kept.
My role — Sole designer and builder: product, workflow design, architecture and implementation — informed by hands-on IAM operations.
How it works
Workflow A — Onboarding
The implemented onboarding path. Example fields are dummy data; connector set is representative, not the full internal inventory.
01Employee request
An operator submits the new joiner’s details — name, work email, employee ID, department, designation, manager, employee type (dummy fields shown; the real form is sheet-configured).
Select any node in the diagram to inspect it.
- Person
- This project
- Internal layer
- Connected system
- Data at rest
- Partial (not built yet)
- Success
- Failed
- Pending
- Skipped
- Info
Workflow B — Offboarding
Partial completion is a first-class outcome — an offboarding with one failed system must never present itself as done.
01Offboarding request
The offboarding starts with a mandatory reason — and can be scheduled for a future date.
Select any node in the diagram to inspect it.
- Person
- This project
- Internal layer
- Connected system
- Success
- Failed
- Pending
Workflow C — User updates
Updates are planned as a diff, previewed, then applied only to systems that support each field.
01Search & load
The operator finds the employee and loads their current attributes.
Select any node in the diagram to inspect it.
- Person
- This project
- Internal layer
- Connected system
- Success
- Skipped
Architecture
Architecture
The current, real implementation — Google Apps Script end to end, with Sheets as the system of record.
- Person
- This project
- Internal layer
- Connected system
- Data at rest
- Person
- This project
- Internal layer
- Connected system
- Data at rest
The stack is deliberately unglamorous: Apps Script (V8) + Google Sheets, deployed with clasp, using Admin SDK and License Manager as advanced services. On-prem systems are reached through a separate allowlisted internal bridge service. A companion asset-management prototype exchanges offboarding status with LifeCycleOne over a shared-secret, allowlisted endpoint.
Planned, not built
Access requests, approval workflows and access reviews exist today only as status plumbing and permission keys — the write side is not implemented, and this page doesn’t pretend otherwise. The same goes for rehire (status constants only). There is no migration to another stack in the source; any future architecture would be a proposal, not work done.
Key engineering decisions
- Onboarding & offboarding workflows
- User360 identity view
- Account updates
- Access management
- Asset visibility
- Multi-system orchestration
Switch to the technical view for the engineering trade-offs behind these.
Challenges & limitations
- Connector actions are not atomic and there is no automatic cross-system rollback; the design answer is per-application visibility and targeted retry, and the page says so rather than implying transactions.
- Active Directory and on-prem tools route through a separate internal bridge service; the connector side is implemented, but end-to-end behavior depends on that bridge.
- Asset visibility is read-only: assigning hardware back is deliberately unimplemented until the tenant’s checkout API is verified, and asset rows are excluded from bulk retry on purpose.
- Approval workflows, access requests and access reviews are planned-only (see above). LifeCycleOne is an operations tool — it is not presented as a replacement for a commercial identity-governance product.
What I learned
Orchestration is the easy half of lifecycle tooling. The value lives in the boring parts — locks around duplicate checks, per-application result rows, fail-safe lookups during offboarding, and result codes honest enough that “skipped” never masquerades as “done.”
Project status
Running implementation on Google Apps Script with 18 registered connectors and all three lifecycle workflows. Presented fully sanitized: no employer identifiers, employee data, tenant object IDs or complete vendor inventory appear here.