In a SaaS where a person can work across multiple organizations or workspaces, “Who created this resource?” does not necessarily answer “Who owns it?” The distinction affects who can view, modify, transfer, or retain it when someone leaves a team. Resolving it late often leaves rules scattered across queries, controllers, and background tasks.
Resource ownership in a multi-user SaaS is a domain decision: it determines which entity has the primary relationship with a resource and what consequences that relationship has. It is not synonymous with authentication, membership, or permissions. Modeling it explicitly allows product, data, and code to share a consistent rule.
Identity, membership, and ownership are different relationships
A user represents an identity that can sign in. Membership means that identity participates in an organization or workspace, possibly with a role or status. Ownership indicates which entity is accountable for a resource under the product’s rules. A person can belong to multiple workspaces and, at the same time, create a document that belongs to one of them.
It is also worth separating authorship. The created_by field can record who performed the initial action, but it should not determine ownership by itself. If the person who created the record leaves the organization, the resource may still belong to it. Conversely, someone could acquire a resource originally created by another person.
It is useful to document the answers to three questions: who owns the resource, who can operate on it, and who performed each relevant action. If the same field or relationship is meant to answer all of them, the model is probably mixing concepts.
Choosing between personal, organizational, or shared ownership
- Personal: the resource belongs to a user. This makes sense when its lifecycle follows that person rather than a team, as with a private preference. Decide what happens if the account is deactivated or deleted.
- Organizational: the resource belongs to an organization or workspace. This is appropriate when the resource should remain available to the team even as its members change. User membership enables access but does not make the user its individual owner.
- Shared: multiple entities can have an ownership or accountability relationship. Use this only if the domain genuinely requires co-ownership. If the requirement is for multiple people to view or edit, that is usually access through memberships or permissions, not multiple owners.
The decision should follow the resource’s lifecycle and business rules, not a preference for simplifying a table. Ask who can retain it, decide to delete it, and be accountable for it when the team changes. Also distinguish “workspace” from “organization”: if the former is a genuine subdivision with its own lifecycle and boundaries, it may be the right owner; if it is only a view or navigation context, perhaps not.
Representing the domain without inferring the owner
In a simple model, a resource table can have an explicit owner, for example owner_type and owner_id, or separate references such as user_id and organization_id. The first option can make it easier to support several owner types, but requires validating references and accounting for the referential integrity limitations of polymorphic relationships. Separate references make the links more explicit, though they require preventing invalid combinations.
Another option is a common entity, such as workspace, if the domain truly represents both personal accounts and teams under it. Do not introduce one merely to hide differences: it should have stable meaning and rules. Whatever the design, establish constraints that prevent a resource from being associated with incompatible owners at the same time—or with no owner when ownership is required.
Model memberships separately, for example with a relationship between a user and an organization that includes status and role. The interface’s active context can indicate where the person is working now, but it is not a sufficient authority: it must be validated for every operation. Likewise, the owner should not be calculated as “whoever created the resource” or “the currently selected organization.”
Enforcing ownership in reads, writes, and automated processes
Queries must include the ownership scope and an appropriate access check. It is not enough to load a resource by ID and trust the interface to hide those that do not belong. In a PHP application, centralize context resolution and authorization rules in a reusable layer, and avoid duplicating incomplete conditions in every controller.
For writes, validate the permitted owner and the actor’s current membership. Also check that related resources—for example, a destination folder—belong to a compatible scope; otherwise, an update can create cross-scope associations. For administrative operations, explicitly separate exceptional authorization from ordinary rules, and record who performed it and why.
Queues, scheduled commands, webhooks, and imports do not always have an interactive user. They should carry a validated owner or context identifier rather than rely on an implicit session. The process must apply the same scope rules as the web application. If it operates with elevated privileges, limit and audit those privileges.
Treating transfer as a domain operation
Changing the owner should not be a generic field edit. Define preconditions: who can initiate the transfer, what relationship the recipient must have with the workspace, and what to do if there is a pending invitation or an inactive account. The operation should be atomic when it updates multiple relationships and associated effects.
Also determine what happens to dependencies such as files, integrations, billing, or automations. Do not assume everything should move along with the resource: that policy depends on the product. If it is not possible to complete all changes in a single transaction, design a recoverable process with clear states and idempotency for retries.
Keep an audit log with the actor, previous owner, new owner, time, and reason where applicable. This distinguishes who authorized the change from who performed the technical action. Original authorship can remain unchanged even when ownership changes.
Testing the boundaries that reveal modeling errors
Automate service and integration tests to verify both permitted and denied access. A useful matrix includes a person in two organizations, resources they own and do not own in both, suspended or revoked memberships, transfer to an ineligible destination, and access through known identifiers. Check responses and data effects; hiding a button does not constitute an authorization test.
Also test resources with no valid owner, duplicate relationships, and failures during a transfer. If the schema requires an owner, database constraints should support that expectation, and migrations should detect inconsistent historical records before adding them. For background tasks, verify that the context is preserved and that a retry does not duplicate changes.
Checklist before scaling the SaaS
- Is it defined whether each resource type belongs to a person, organization, or workspace?
- Are ownership, authorship, membership, role, and active context distinguished?
- Do read and write queries validate the owner and current membership?
- Do automated tasks receive an explicit scope and apply equivalent controls?
- Does transfer have preconditions, defined effects, auditing, and a recovery strategy?
- Are there tests for users with multiple workspaces, departures, cross-scope access, and inconsistent data?
If any answer depends on undocumented conventions, clarify it before adding more resource types or collaboration flows. An explicit model does not eliminate every complex case, but it makes decisions visible and lets you verify them in the schema, queries, and tests.
