ReleaseSignoffYour data
What ReleaseSignoff stores, and where
A release heat map is a client deliverable. Before you put one anywhere, you should know exactly what is being uploaded and who can reach it. This page says so plainly, including the parts that are still limitations.
What gets uploaded
One file per release, and optionally a second:
- The What's New heat map as your tenant delivers it: feature names, descriptions, functional areas, and the highlighting your team applied.
- Optionally, the Feature Release Testing Workbook, if you use one: test scenario names, descriptions and execution status.
Neither file contains people. Reviewers are added in the app instead, by an admin typing a name and a work email address. That email address is what the sign-in link is sent to, and together with the name it is the only personal data ReleaseSignoff holds about anyone.
No worker records, and no connection to your tenant. ReleaseSignoff holds no Workday credentials and has no integration that could reach employee records. It reads the spreadsheets you upload, plus the reviewers you add by hand, and nothing else.
Where it is hosted
The application runs on Cloudflare's network. Data is stored in a managed Postgres database hosted on AWS in the United States, with encryption in transit and at rest. If your organisation needs data resident in a specific region, say so before you upload anything, because that is not something I can currently offer and I would rather tell you now.
Who can see what
Access is enforced in the database itself, not just in the interface, using row-level security. Every table that holds your data is scoped to an organisation, and a query from a user who is not a member of that organisation returns nothing at all, regardless of what the application asks for. Two tables sit outside that scoping and neither holds customer data: the list of spreadsheet column-name variants the importer recognises, and the contact form's inbox, which nothing can read back.
| Who | Can see |
|---|---|
| A reviewer | Only the organisations they are a member of. Within those, the features and scenarios for that release. |
| An organisation admin | The same, plus importing releases, managing people and assigning functional areas, for their own organisations. Adding someone creates a sign-in account for that email address on that organisation only. |
| An account owner | The clients under their own account, and the people on them. A consultancy running releases for several clients has one account with several clients under it; an account owner can never see or reach a client belonging to a different account. |
| Someone with an account but no membership | Nothing. Authenticating is not the same as being authorised, and an account with no organisation membership returns no rows. |
| Another organisation | Nothing. There is no shared view and no cross-organisation reporting. |
Accounts
Sign-in is by emailed link, so for most accounts there is no password to store or leak. A password option also exists, which I use for shared demonstration accounts; it is not restricted in code, so any account that has a password set can use it. There is no self-serve signup: an account has to be added to an organisation deliberately, which means a stranger who requests a sign-in link gets an account that can see nothing.
Deleting your data
Ask and an organisation's data is deleted, including its releases, features, reviewers and review history. There is no retention period I need to hold it for. If you would rather remove a single release, that works too.
What this page is not
ReleaseSignoff is a new product built by one person. It has not been through SOC 2, ISO 27001, or a third-party penetration test, and it would be dishonest to imply otherwise. If your procurement process requires any of those, it is not ready for you yet, and I would rather say that here than three weeks into an evaluation.
Question this page does not answer?
Ask before you upload anything. I would rather answer a hard question now.