Append-only, from day one
Every state change writes a line that is never updated and never deleted. Not a setting, not a premium tier — there is no code path that edits history, because retroactive audit can't be added to a system later.
Records & security
The record holds up
If you're routing approvals, the record is the product. Here's what Orgworks guarantees about it, and how those guarantees are built rather than promised.
Sec. 1 — The audit record
Written with the thing it describes
The record and the state change are committed together, in one transaction. Either both happened or neither did. You can't get an approval without its record, or a record of an approval that didn't take.
Who you asked, as of when you asked
Assignments are resolved when a step opens and written down right then. When the org chart changes next quarter, the record still shows who was actually asked — not who would be asked today.
Sec. 2 — Documents
Versions, never overwrites
Uploading again creates a new version alongside the old one. Nothing in the product replaces a document in place, so "which copy did they see" always has an answer.
Fingerprinted
Every version is hashed on the way in. You can prove the file you're holding is the file that was approved.
Approvals capture the table
When someone approves, the record snapshots every document and version that was in the bundle at that moment. An upload after the fact can't quietly become something that was already signed off.
Archived where you can find them
An archive step copies the current version of everything to archive storage and stamps the request with the location. Running it twice is harmless.
Sec. 3 — Access
Organizations can't see each other
- Every record carries its organization, on every table, since the first migration
- Every read and write is scoped by it — not by a filter someone remembers to add
- Tested as a property of the system, not as a checklist item
Actions are authorized against the record
- You can act on a task because the record says it was assigned to you
- Only the person who started a request can cancel it
- A bundle is visible to the organization that owns the request, and no one else
External links do one thing
- A signed link names exactly one task and nothing else
- It expires — 14 days by default
- Editing the link invalidates it; the signature is the point
- It opens only that request's documents, only for that task
- Acting through it runs every rule a signed-in action does
- Replaying it, or using it after the request closes, does nothing
External still means attributed
- "External" is about not logging in, not about being anonymous
- Board members are real members of your organization who never sign in
- Their votes attribute to them identically to anyone else's
- The timeline doesn't have a second-class citizen on it
Sec. 4 — Under load, and under failure
Nothing lives in memory
A request can sit for six weeks across a dozen deploys. Its state is in the database, not in a process, so restarts, deploys, and a lost server cost you nothing.
Simultaneous approvals serialize
Two people approving the same step in the same second can't both win, double- advance a request, or corrupt the count. One goes through, the other is retried against the new state.
Automation can't be half-done
Every email, reminder, escalation, and automatic step is queued in the same transaction as the change that caused it. An approval that commits always sends its notifications; one that doesn't, never does.
See it route something of yours
Bring a workflow you run on email today — an approval chain, a renewal, a board packet. We'll build it as a Template on the call and walk a real Request through it.
Request a demo
30 minutes. No slides.