Manage Team permissions

Organizations and Projects

Each Organization belongs to a specific Region and can contain one or more Projects. A mandatory Administrators Team exists at the Organization level with full access to all Projects and resources. Only Administrators can manage users, Teams, and permissions.

Teams and roles

Teams are created and assigned to one or more Projects. Team members are assigned roles, which define permissions associated with a scope. Permissions can vary across Projects. For example, a Developer role might have full access in a staging Project but only limited read access in production.

To achieve this flexibility, you should define the scope of a role at the Project level. You can grant access to all Projects to a role within the Organization or restrict access to a specific subset of Projects, with each Project potentially having different permissions for the same role. This granular control is useful for managing access across different environments, such as production and staging, where security and access requirements often differ.

Effective permissions

A user's effective permissions are the combination (union) of all permissions granted by the user's roles across their Teams. For example, if a user has view permissions in Team A and manage permissions in Team B, they gain both view and manage permissions.

Scopes

Scopes define the resources a role can access and the related action rights (for example, view, manage, create). Scopes can target specific Categories, Products, or Orders. For more details, refer to Permissions and Action Rights.

Best practices

Let’s check out some of the best practices to effectively manage Team permissions.

Administrators Team

Carefully consider who should be granted administrator privileges within your organization. Balance the need for a sufficient number of administrators to handle urgent access requests with the security risk of having too many. Limiting the number of administrators reduces the potential for abuse and helps maintain a secure environment. Ensure adequate coverage for handling urgent matters, such as distributing responsibilities across multiple administrators or establishing clear escalation procedures.

As administrators have the power to modify user permissions, including adding or removing other administrators, this role should be reserved for trusted individuals with a thorough understanding of Merchant Center permissions.

When granting access to third parties, create a dedicated Team to isolate their permissions, simplifying management and revocation.

Developer settings permission

The "Developer settings" permission grants a user the powerful ability to create API Clients with any scope. This effectively allows full access to the API for the Projects accessible to that user's team, enabling them to create, read, update, and delete any data.

You can mitigate the risks of this broad permission by doing the following:

• Restrict access: grant this permission only to trusted teams and preferably only within non-production environments.
• Centralize API Client management: consider assigning administrators to manage API Clients and grant specific permissions, ensuring secure sharing of credentials.
• Principle of least privilege: always adhere to the principle of least privilege. Only grant the necessary permissions required for a user or API client to perform their specific tasks.

By implementing these strategies, you can leverage the flexibility of API Clients while maintaining a secure and controlled environment.

Audit Log permission

Giving access to the Audit Log can also unintentionally leak extra information if the wrong users have access. This is because the Audit Log contains a history of changes for all records, and so a user with this permission could see partial information about Orders, Customers, Discounts, and all other entries in Composable Commerce. Because of this, you should only give this permission to Teams that should also have the ability to view the underlying data the Audit Log entries refer to. In other words, access to the Audit Log should generally mirror the data access permissions already granted to a Team.

Do not grant Audit Log access to users who don't have permission to see the data being audited. The principle of least privilege helps minimize the risk of unintended data exposure.

When using Audit Log, remember that it tracks all changes from the Merchant Center so you will have visibility on changes made by users. However, only Audit Log Premium tracks changes made by API Clients.

Managing access across multiple brands and companies

Project-level access control in Composable Commerce offers significant advantages beyond managing development environments. It's valuable for organizations with complex structures, such as those operating multiple distinct brands or subsidiary companies.

Let’s explore the example of Zen Electron, a fictional parent company overseeing two separate entities: Zenith Living (New Zealand) and Electronics & Tech (Australia).

Each subsidiary operates independently, with dedicated teams and distinct data sets. Zenith Living focuses on home goods and operates exclusively in New Zealand, while Electronics & Tech specializes in consumer electronics within the Australian market. It's crucial that sensitive data, such as sales figures, customer information, and product strategies, remain isolated between these entities.

Composable Commerce allows Zen Electron to achieve this separation by leveraging Project-level permissions. Each subsidiary can be assigned its own Composable Commerce Project, offering granular control over access and the following benefits:

• Data isolation: Teams at Zenith Living can be granted access only to the Zenith Living Project, preventing them from viewing or modifying any data related to Electronics & Tech. The same principle applies to the Electronics & Tech teams, ensuring complete data segregation.
• Localized control: user management can be decentralized. Each subsidiary can manage its own user accounts, roles, and permissions within their respective Projects. This empowers local administrators and reduces the burden on central IT.
• Simplified administration: by mirroring the organizational structure within Composable Commerce, administrative overhead is significantly reduced. Onboarding and offboarding users becomes a straightforward process, as access is managed within the context of each specific Project.
• Enhanced security: Project-level access control minimizes the risk of accidental data exposure or unauthorized modification. Even users with elevated privileges within one Project are completely restricted from accessing data in other Projects.

This approach allows Zen Electron to maintain a unified experience while ensuring strict data separation and localized control for its subsidiaries. It demonstrates how Project-level access control in Composable Commerce can effectively support complex organizational structures and enhance security across multiple brands and companies.

To learn how you might do this with Projects and Stores, read our Stores and Channels module.

Case study: create a set of teams with varied access

Buy Now, a fictional growing digital commerce company, recognized the critical need for robust access control within their Composable Commerce Merchant Center. John, the Director of IT and Security, understood that balancing user productivity with data protection was paramount.

The Composable Commerce solution for Buy Now consists of three Projects: Production, Staging, and Development.

Buy Now has initiated a review of access privileges, focusing on aligning permissions with individual responsibilities based on roles.

The key players and their needs:

• David, Lead Developer: David and his Team require full access to the development and staging environments to build and test new features. However, the Team's access to the Production Project needs to be restricted to read-only except for Discounts, Products, and Categories for debugging purposes, minimizing the risk of accidental changes. Only David can have read and write access on Production, because of their seniority and trust.
• Maria, Marketing Director: Maria's Team needs to manage Product information and Discounts. However, they shouldn't have access to sensitive data like Customer information.
• Alex, Customer Support Manager: Alex's team requires access to Customer and Order data to resolve customer inquiries, manage returns and give customers Discount Codes when they have a bad experience. Their access needs to be limited to the production environment and restricted to actions directly related to customer support.
• Bob, External SEO Consultant: Bob, contracted for a short-term project, needs access to optimize Product information for search engines. His access should be limited to the Staging Project and revoked upon project completion. Product information is periodically synced from Staging to Production.

Implementing the solution in Composable Commerce

John leveraged the granular access control features of Composable Commerce to implement a robust permission structure:

John also granted Steve Robs, the founder, Administrator privileges to ensure redundant access management capabilities.

Security and efficiency achieved

This structured approach provides a secure and efficient access control model. Each Team member has only the permissions necessary for their role, minimizing the risk of unauthorized access or unintended data modification. By avoiding additive permissions and ensuring each user type belongs to only one Team, John has simplified user management and streamlined the process of revoking access, as demonstrated with the planned removal of Bob's access upon contract completion.

This strategy not only enhances security but also improves operational efficiency by providing a clear and well-defined access framework. The implementation underscores the importance of aligning access privileges with responsibilities, a critical element in maintaining a secure and productive digital commerce environment.

Test your knowledge