# Organization lifecycle: the trio again
`organization.created`, `organization.updated`, `organization.deleted`. Same discipline as the user trio: subscribe to all three, one sync function, org id as the key.
## What to do on receipt
1. On `organization.created`: create your local org record keyed by `evt.data.id`. Store `name` and `slug`. If you provision per-org resources (a workspace, a billing customer, default roles), provision them here, idempotently.
2. On `organization.updated`: upsert name, slug, and metadata. Slug changes break URLs; if you build org URLs from the slug, update your routes or redirects on this event.
3. On `organization.deleted`: tear down or archive the org's data in your app. Decide the policy once: hard delete, soft delete, or transfer ownership. Then apply it here, not ad hoc later.
4. Return 200.
## The trap
Provisioning on created but never tearing down on deleted. Orphaned workspaces, billing customers, and storage buckets accumulate silently because the delete event was never subscribed. The trio rule from the user events applies verbatim.
## Checklist
- Org membership changes are separate events (organizationMembership.*). Do not conflate "org updated" with "someone joined."
- If you sync orgs, you almost certainly need the membership events too. An org record without its member list is half a sync.
- Test deletion with a throwaway org and a replay. Deletion paths are the least tested and the most destructive when wrong.