Roles and authorizations - concept
Why Assign Roles?
In a small team, it’s tempting to give everyone the same role. It’s easier to manage—but it comes with risks. If every member can delete sources, a single accidental click can remove an entire dataset. If every member can create API tokens, it becomes harder to completely revoke access when an employee leaves.
Picasa’s four roles solve this problem with a tiered access model: Each role has exactly the permissions it needs to perform its tasks—and nothing more.
The four roles and their typical use cases
Owner is usually the person who created the account—typically a marketing director or executive. They have full access, including billing permissions. There is exactly one owner per workspace.
Admin is the right role for anyone who actively manages the workspace: creating sources, setting up channels, configuring tags, inviting team members. These are typically marketing managers or agencies that manage the workspace for clients.
Member is the most common role for active users: evaluating the inbox, generating AI reports, reading reports. Anyone who works with updates on a daily basis needs this role—but does not require admin access.
Reader is intended for people who are only consuming content: reading reports, viewing updates, without being able to intervene in the workflow. This is suitable for stakeholders who want to stay regularly updated but do not actively work in Picasi.
Special Considerations for Agencies
If an agency uses Picasi for multiple clients, there are two scenarios:
Either the agency has separate workspaces for each client—in which case the agency is the owner and assigns roles to client contacts. This gives the client visibility without control over the workspace configuration.
Or the client is the owner of their own workspace and invites the agency as an admin. This is the more transparent option because the client retains full access and control.
What to Consider When Changing Roles
If you downgrade a member to a lower access level (e.g., from admin to member), they immediately lose access to restricted areas. This can lead to surprises in ongoing processes—clarify such changes in advance.
When a member leaves the workspace, their membership, as well as any API tokens and OAuth connections, are revoked.