How ProjectSmith keeps tenants separate
ProjectSmith is a multi-tenant service: many MSPs use the same application, and each has its own workspace (a tenant). Keeping one workspace’s data away from every other is the first rule of how ProjectSmith is built, and we treat any breach of it as a top-priority security incident, not a bug.
Every record carries its workspace
Section titled “Every record carries its workspace”Every piece of your data in ProjectSmith (projects, tasks, time, leave, allocations, settings, and the copy of your Autotask data) is stored with your workspace’s identifier.
- The database filters every read and write by workspace. The filter is applied centrally, so a screen or report can’t forget it.
- Your workspace is decided by your sign-in, never by anything your browser sends in a request. Changing a web address or a request can’t point you at another workspace’s data.
- Records copied from Autotask are keyed by workspace and Autotask ID together. Two MSPs whose Autotask happens to use the same ID for different tickets can never see each other’s.
Tested on every change
Section titled “Tested on every change”For every kind of record, ProjectSmith has an automated isolation test that checks one workspace can’t read, change or delete another workspace’s records. These tests run on every change to the code, and a change can’t be released if any of them fails.
Background work runs one workspace at a time
Section titled “Background work runs one workspace at a time”Syncing with Autotask, sending email and other background jobs run as one job per workspace. Each job knows which workspace it’s working for before it touches any data, and the same database filter applies. Cached data is stored per workspace too.
Your Autotask credentials
Section titled “Your Autotask credentials”Your Autotask API user’s secret is encrypted before it’s stored, with keys held separately in Azure Key Vault. It’s used only by your workspace’s connector, and it’s never displayed again after you save it. Each workspace connects with its own API user, to its own Autotask; the connector can’t be pointed at anyone else’s.
ProjectSmith staff access
Section titled “ProjectSmith staff access”ProjectSmith staff sign in to a separate administration portal through a separate staff directory, with multi-factor authentication.
- Staff don’t see your data in the normal course of running the service.
- When support does need to look at a workspace’s data, for example to investigate a problem you’ve reported, access goes through a single controlled path that requires a reason and records who looked, when and why in an audit log.
- There is no other way around the workspace filter.
An audit trail of changes
Section titled “An audit trail of changes”Every change made in ProjectSmith, by your users or by staff, is written to an audit log: who did it, what changed, and when. Your workspace’s Owners and Admins can read and export the changes made in the workspace, including those made by ProjectSmith support, in the audit log. Staff access to your data is recorded, with the reason, in ProjectSmith’s platform audit log, and we send you that record on request.
Regions
Section titled “Regions”Each workspace lives in one region for its whole life. Workspaces are hosted in Australia today; United Kingdom and United States regions are planned. See Data residency and sub-processors.
Common questions
Section titled “Common questions”Is my data in a separate database? No. Workspaces in a region share a database, separated by the controls above.
Can another ProjectSmith customer ever see my Autotask data? No. That’s what every control on this page exists to prevent, and what the isolation tests check on every change.