SaaS permissions: let people work without admin access

A client project should not stop because the only person who can upload a revision is the agency owner. Useful SaaS permissions let people finish the work they were hired to do, with access that matches their responsibility.

Consider a fictional agency using a project-delivery platform. Maya, a freelance designer, has finished a revised campaign layout for a US retail client. She can read the brief and see review comments, but replacing a draft file requires an administrator. The account lead is waiting for the revision before the afternoon review.

Someone suggests making Maya an admin for the week. That would unblock the upload. It would also give her control over projects she has never worked on. Following this small delay through the product reveals a better way to delegate: define the job, the material it touches, and how the person can get back to work.

Start with the revision Maya needs to upload

The support request says “Give our freelancer admin access.” Taken literally, that sounds like an account-management task. Ask what happened just before the request, and the problem becomes much more specific: Maya needs to add a new version to an existing deliverable in one client project.

She does not need to change workspace settings or invite more people. The account lead still decides which version is ready for the client. Those responsibilities can stay separate while Maya takes ownership of her part of the work.

There is a useful real-world example in GitHub's outside collaborator role. A consultant can have access to particular organization repositories without becoming an organization member. It illustrates a practical distinction: participating in a specific piece of work does not have to mean joining everything around it.

For our fictional platform, “Project contributor” could be a useful role if the agency routinely hires designers to do the same work. The description should explain what that includes. A reassuring role name is little help if the person sending the invitation still has to guess whether it allows publishing a draft.

Keep the permission attached to the right project

The next question is where Maya can upload. The agency has other clients, and even this retail client has another campaign underway. Granting access to every project under the same customer would reach beyond the assignment.

The proposed invitation therefore names both the responsibility and the project: Maya can read the brief, comment, and add draft versions to the fall campaign. Sending a version to the client for approval remains with the account lead. The lead can review that scope before issuing the invitation.

The platform also needs a reliable boundary between agency accounts. OWASP's multitenant guidance says tenant context should be tied to a verified identity and authorization. An agency identifier supplied by the browser is a selection to check, rather than proof that the caller belongs there.

Inside the agency, project membership supplies another boundary. A contractor might work on two campaigns with different responsibilities in each. Showing those assignments together would help an account lead answer a familiar operational question: “What exactly can Maya work on today?”

Give a blocked person a useful next step

Before the invitation is corrected, the upload screen can explain the gap. “You can view this project. Ask its account lead for permission to add draft versions” tells Maya what is missing and who can decide. “Access denied” leaves her guessing whether the file, her account, or the entire project is broken.

A request-access flow could carry the project and intended action to the lead. That avoids a second round of messages translating an internal permission name. It also makes the decision easier to review than a request for unrestricted access.

The product can remember which deliverable Maya was working on. Once access is granted, it should let her return, inspect the latest version, and choose to upload. Perhaps a colleague added another revision while she waited. Automatically replaying her earlier attempt could overwrite the wrong version or start a review with an outdated file.

Make the server enforce what the invitation promised

Hiding an admin button changes the interface; it does not secure the underlying action. OWASP recommends checking authorization on every request, with enforcement in a trusted layer such as the server. A successful sign-in does not authorize every operation.

The product team can test the invitation using fictional files. Maya should be able to add a draft in her assigned project. An upload directed at another project should fail. A request to send the draft to the client should also fail, even if it is made without using the visible interface.

These are two different boundaries: the material she can work on and the actions she can take with it. Passing only the first test would still leave the agency's review process exposed. The account lead needs the actual behavior to match the responsibility described when inviting Maya.

Finish the engagement without losing the work

The campaign is delivered and Maya's assignment ends. The lead removes her project access. Her uploaded versions remain part of the project record, with clear authorship, so the next designer can understand what was delivered.

In a test session that is already open, a fresh attempt to upload or retrieve protected project material should now be denied. OWASP's guidance on caching makes clear that cached data still requires authorization and that refresh behavior must account for access risk.

Removing platform access cannot make a file Maya previously downloaded disappear from her laptop. That limit should shape what the agency shares at the start. The invitation can be narrow enough to support the assignment without including unrelated client material.

If someone later asks who replaced a draft, a useful activity record should answer that question. OWASP recommends recording enough event context for analysis, including the actor, action, timing, and result. For this workflow, the relevant event can point to the project and version without duplicating the client's full brief in a log.

Let the next project move without the owner

On Maya's next engagement, the lead invites her to the new project with the intended permissions. She uploads her draft, the lead reviews it, and the client receives the selected version. Each person can complete the part they own. The agency owner no longer has to relay files simply because the product bundled routine contribution with administration.

Look at the last time a customer asked your SaaS team for more access. Find the unfinished task behind that request and follow it to completion. You may discover a small permission change that removes a recurring interruption while making the customer's delegation easier to understand.