OrgTools is organized into organizations. This can be thought of as your company’s OrgTools account, in that you will typically only be in one organization at a given time.
Organizations contain projects. Projects organize a set of data operations that are related. For example, you may choose to organize your workflow by assigning one project per client, or alternatively, one project per feature.
Projects contain data templates. Data templates is the method used to allow you to provide rules for how you want OrgTools to implement your data copy.
Organization Level and Project Level
OrgTools operations occur at the organization level and at the project level. This means that certain operations (i.e. data masking) can be configured to apply to the entire organization and its descendants (projects and data templates) or can be configured to apply to a specific projects and its descendants (data templates) and thereby operating at the project level.
Organization Level
For example, an administrator wants to create a masking definition that will automatically mask social security numbers for their entire organization. To do so, they would apply the data mask at the organization level in Organization Settings (see Apply Data Mask To Project or Organization).
A masking definition created at the organization level applies to all projects, and to all data templates within each of those projects.
Project Level
Just as a masking definition can be created at the organization level and its configuration will be inherited by all of its descendants, a masking definition created at the project level will pass on its configuration to the data templates in that project.
Note: certain OrgTools features are tied to project. In other words, when creating them, you must specify what project they will apply to. Examples of these include billing accounts and data templates.
OrgTools Workflow
To help you decide how to best approach creating your company’s workflow inside of OrgTools, below are the structures of three different types of companies: a consulting company, a Fortune 500 company, and a small business.
A consulting company may choose to create a project per client, housing all relevant data copies for that client in one place. They are still able to create data masks that will apply across the entire organization, saving time in cases when the same data mask rules apply for all clients.
A Fortune 500 company may choose to create an organization per region and within each organization, create projects per client or department.
A small business may only need one project to keep track of all of their data copies.
Choosing Your Salesforce Sandbox
To help you decide the Salesforce Sandbox that is best suited for your project, below is a breakdown of the different sandboxes and their use case in the development cycle.
Full Sandbox
This is a copy of your production org including data and metadata.
Partial Copy Sandbox
This copies the metadata, and a sample of your production organization's data.
Developer Pro Sandbox
This copies customization (metadata), it doesn't copy production data, but has more storage than Developer sandbox.
Developer Sandbox
This sandbox includes a copy of your production org’s metadata.
|
Development Environment |
Use Case |
Refresh |
User Licenses |
Data Storage |
|
Integration Test, Batch Data Test, Training, UAT, Perf/Load Test, Staging |
29 days |
Same as production environment |
||
|
Build, QA, Testing (Integration Test, Batch Data Test, Training, UAT) |
5 days |
Same as production environment |
5 GB data |
|
|
Build, QA |
Once per day |
Same as production environment |
1 GB data |
|
|
Developer Sandbox |
Build, QA |
Once per day |
200 MB data |
|
Release Management
Production
Staging / User Acceptance Testing (UAT)
Full testing of all functionality with Integrations
Quality Assurance
All development work pulled into a sandbox to ensure interoperability and code coverage testing.
Development
Each major initiative or project
Figure 1.
Figure 2.
Figure 3. Standard Environment