As a salesforce admin or developer maintaining a salesforce org, there is always a question of what and how to analyze an impact of a change or a new feature. There is always issues of falling short on the analysis which results in issues during deployment and results in errors for users. Executives and users point fingers on why it was not thought through and it always ends up falling short. There is always thousand ways of testing a change and here is a simple approach of preventing a change to cause errors on pages and downtime issues.

1. Identify the type of change.

In Salesforce there is always 2 types of changes namely configuration changes and apex level code changes. We are going to focus on configuration change which can range from simple changes like adding new fields, changing existing fields on custom and standard objects to complex changes like workflow rules, approval changes etc.

2. Start with data .

Identify the object directly impacted by the change like Lead, Account or custom object. For the impacted object, make a list of related objects which are generally objects which have a master detailed and child relationship.

a. For each of the object, identify pages where users can create records and update records for the object and make a list of them.

b. If there are visual force pages , identify the pages and make a list.

3. Validate impact on users

Once the objects are identified, look at the profiles and make a list of profiles which have read, create,edit and delete permissions. Identify 1 to 2 active users who are part of the profile and test the change by logging in as those user. This would become your test case for validating the change.

4. Validate impact on security

Look at the organization wide defaults for those objects and create scenarios for testing the scenario. For e.g if the organization wide default is private, there should be a scenario for logging in as a user who owns the record and check if you are able to view the records.

Then make a list of sharing rules for the object and create a spreadsheet matrix which would have columns for records shared,  users who create the record and users whom the records would be shared with . This would help you to test the granular permissions sharing rule for each change.

6. Validate impact on Automation.

Check if your change impacts any workflow rule, approval process and triggers. For each automation feature, it is important to create scenarios to test your change.

7. Validate deployment and non deployment of change.

For any change, it is always a best practice to identify scenarios on how to validate if a change has been deployed successfully and failed to make it. For e.g if it is a field type or new field created, identifying the page where the field will show up would help to validate the success of the change. If the change is not deployed, our alternate test scenario should cover the failure of deployment of the change.

So using this simpler techniques, we can ensure that configuration changes in salesforce will be deployed to production without any errors. Please feel free to email me at buyan@sforcemaximizer.com or please click like if you like my post.