Security and organization access
Customer imports belong to an organization and project. Access is controlled by membership and role, rather than by hiding dashboard links.
What protects organization boundaries?
The application uses Supabase Auth and database row-level security policies. The supplied migrations restrict organization records to members and restrict changes by role. These protections depend on the deployment applying the migrations and preserving those policies. Customer delivery data is not included in public pages or the public sample project.
Who can access imported work?
Organization members can read their organization’s data. Owners and admins manage projects and deletion; members can import; viewers have read access. The operator of the Supabase service has administrative database access. Organization membership is not a substitute for minimizing sensitive fields before import.
Support staff
Internal support staff sign in to a separate staff console with multi-factor authentication. Their actions there are recorded in an audit log with the time, IP address and browser user agent, kept for 2 years. Staff accounts have no database access to customer organization data.
Roles and what each can do
| Role | Can | Cannot |
|---|---|---|
| Owner | Everything an admin can, plus delete the organization and grant or remove ownership | Leave the organization without another owner in place — an organization always keeps at least one owner |
| Admin | Manage projects, integration configuration and members; delete imports and project data | Grant, remove or demote ownership |
| Member | Read the organization’s data, import delivery files and edit field mappings | Manage projects or integration connections, or delete imports |
| Viewer | Read the organization’s data | Change anything |
Why a changed browser request cannot reach another organization
Organization boundaries are enforced by the database, not by the dashboard. Every organization table has row-level security, so a query without any filter still returns only the rows of organizations the signed-in user belongs to. Records are linked with keys that include the organization, so a row cannot be attached to another organization’s project by editing an identifier in a request. The browser only ever holds the public, low-privilege database key; the application refuses to start if a privileged key is configured for the browser.
Integration credentials
CSV imports need no credentials for your work-tracking tool. A direct Jira connection (part of VeloWise Pro) uses Atlassian OAuth 2.0: you sign in to Atlassian and approve read-only scopes plus offline access, so VeloWise never asks for your Jira password or an API token. The resulting access and refresh tokens are encrypted with AES-256-GCM and stored in a private server-side table that browser roles cannot read or change; only the server-side import function decrypts them. Disconnecting deletes the stored tokens. Atlassian does not offer apps a way to revoke them, so also remove VeloWise from your Atlassian account at id.atlassian.com/manage-profile/apps. A Jira site saved on an organization stores only the site address, connection type and status. See integration compatibility.
How isolation is tested
The database migrations run in an automated test suite that signs in as different users and tries to cross organization boundaries: unfiltered queries, forged organization identifiers, updates and deletes against another organization, adding oneself to another organization, anonymous access and role escalation. Each of these must return nothing or be rejected. Deletion is tested too: deleting an import, project or organization removes exactly its own data.
Report a security issue
Report a suspected vulnerability to the operator of this deployment. Include the affected URL, the steps to reproduce it and what you observed. Do not access or change data that is not yours, and do not degrade the service while testing. This deployment’s machine-readable contact file is at /.well-known/security.txt.
What is outside this guarantee?
Browser storage is available to people using the same browser profile, and extensions may read pages. Exported reports are ordinary files under your control. This project does not claim SOC 2 certification, an independent security audit, or a service-level agreement.
Before importing company data
Check your company’s authorization to use this deployment, review organization membership, and omit unnecessary descriptions or personal information. Review the deployment’s authentication providers and database configuration with its operator.
Usage analytics and your choices
Product events measure signup, import and first analysis with allowlisted categories. They exclude imported delivery content, organization names and email addresses. Google Analytics and ads load only after you accept them in the consent banner, and you can change that choice on the privacy page. Google Analytics may use browser identifiers; these events should not be described as anonymous. Ads appear only on public educational pages for signed-out visitors, never in the workspace.
Privacy and local deletion controls · Data storage and deletion details · How analysis uses your data
Start with data you are authorized to use
Import delivery data and analyze it in your browser. You can explore the synthetic sample first.
Analyze your delivery data