Policy Lifecycle Redesign
Rebuilding how compliance policies are drafted, renewed, corrected, and distributed inside Rippling so lifecycle state is explicit instead of scattered across products.
Overview
Policy work sat outside the main compliance flow: drafting meant bouncing out to the Documents app, renewal was a reminder email and a manual pass, and distribution was ad hoc. Customers were using several products to complete one compliance job, which made state hard to see.
I took over the Policy project mid-stream and led the technical redesign. The goal was to bring the workflow into Automated Compliance with renewal, correction, and distribution as explicit states rather than follow-up tasks.
What I built
Drafting lives in Automated Compliance now, so a compliance officer can write a policy document end to end without leaving the product. The backend models the lifecycle directly: a policy knows whether it is in review, active, due for renewal, or being corrected. That gives the UI explicit states to mirror instead of making the user infer them.
The renewal flow carried the most product weight. Previously, renewal was a date and a reminder. Now the system tracks which policies are due, creates the next revision from the current active version, and walks the owner through distribution. Corrections follow the same lifecycle when an active policy needs a targeted update. Revision records and state transitions preserve who changed what, when they changed it, and why the policy moved forward.
Product design set the workflow intent. Much of my implementation work was translating that intent into state machines that would hold up under edge cases, like a policy corrected mid-renewal or a distribution that fails partway through.
Collaboration
Product design shaped the new workflow, and the previous technical owner helped me preserve existing customer commitments while changing the lifecycle model underneath.
Outcome
- Policy drafting, renewal, correction, and distribution were implemented as one lifecycle path.
- Renewal moved from reminder-only workarounds to due-policy tracking, next-revision creation, correction, and distribution inside one lifecycle.
- Revision history, actors, timestamps, and state transitions are recorded as part of the lifecycle.
I treated existing commitments and partial implementation as constraints to preserve, not reasons to restart. The redesign kept the pieces that already worked and focused on the places where users needed clearer lifecycle state.