- 2Installing Flosum
- 3Setting up Flosum integration user
- 4Connecting sandboxes to Flosum
- 5Setting up users in Flosum
- 6Setting org permissions
- 7Decide on naming convention
- 8Initialize the repository
- 9Setting up workflow permissions Application Development Flow
- 10Pulling changes from dev sandboxes
- 11Branching strategy
- 12Conflict and Merge strategy
- 13Static Code Analysis
- 15Regression testing
- 16Reference Architecture Integrations
- 18TFS/Azure Devops
- 19Git Integrations Compliance & Governance
- 20Compliance & Governance
With Flosum, you can control the access to each org. By default, users do not have access to any org until they are explicitly assigned access. The Org Permissions related list shows the roles of the various team members who have been given access to this particular org. Flosum ships out-of-the-box roles which allow you to grant read-only and read-write access to a particular orgs.
What are the different roles in Flosum?
The following are supported roles:
Read-only: Can only view the details. Read-only cannot create snapshots or deploy code to that org.
Developer: Can create snapshots for that org, but cannot deploy any code changes to that org.
Release Manager: has full access to the org. Release Managers can create snapshots as well as deploy changes to that org.
Who can grant access to these roles?
The roles can be granted by the owner of that org. The user who registers the org is typically the owner of that org.
What is the scope of each role?
The scope of each role is limited to that org. So, a user can be developer for one org and release manager for another org.
Extending & Customizing Flosum:
Flosum is built on and supports the complete security model of the Salesforce platform. The complete sharing model can be leveraged by customers to customize the Flosum security. All the details of the Security model can be seen in the Salesforce Security Guide.
In addition to that, Flosum has extended the Salesforce security model. Using Apex sharing rules, customers can grant different levels of access to various users for the same org. So, a developer may have full access to the QA organization, but no access to the UAT, System Integration testing or Production environment. Similarly, a QA person can only have access to the UAT and Production environment.
Customers can create a matrix to define the org permissions for the various sandboxes.