# Sunday, 21 November 2010

"How can I add a picklist field?"
"Can I modify this report?"
"Would you please update the Lead trigger to de-dupe by email address?"

Salesforce Administrators are faced with these, and many more questions on a routine basis. Salesforce.com CRM provides sufficiently granular access permissions to control precisely what an end user can and cannot do. As end users click around Salesforce, the general rule is "If you can do it, you probably have permission". However, the same thing cannot be said for System and Delegated Administrators.

Once a user is given administrative access to application settings, then more training and monitoring must be imposed. In short, a "change management process" must be implemented.

There are a number of business drivers for a change management process:
  1. Compliance - Your industry may require that certain changes be reviewed, approved, documented, and deployed in a methodical way
  2. Productivity - The smallest change in a user interface can result in hours of lost productivity if users aren't given advance warning or training
  3. Reliability - Prevent the deployment of changes that may break existing workflows or processes

Change management processes attempt to answer all or some of the following questions:
  • Who approved and/or made the change?
  • Why was the change needed?
  • When was the change made?
  • How was the change deployed?

A change management matrix can help identify how each type of change should be managed.

Steps for creating a change management matrix:
  • Create a list of common Salesforce changes in a spreadsheet
  • Define a spectrum of change management categories (For example, red/yellow/green lights)
  • Periodically sit down with all Sys Admins, Developers and Approvers and review how the organization should respond to each type of change category
  • There will always be exceptions. Add an "Exceptions" column to the matrix and document them
  • Train admins on the use of built-in auditing tools to ensure compliance with the CM process

Sunday, 21 November 2010 14:51:08 (Pacific Standard Time, UTC-08:00)
Good post - The matrix is a very good way to identify the change items using the metadata types.

I would add that the 3. Reliability (or impact assessment) should also try to identify whether the proposed change has an effect on future functionality (for example making a change to opportunity products might prevent customizable forecasting from being activated).

Also, I guess depending on the company structure, exceptions might be needed for emergency changes (due to say new regulatory or break-fix requirements) which must be implemented urgently and cannot be included in a scheduled release window.
Sunday, 21 November 2010 15:03:37 (Pacific Standard Time, UTC-08:00)
It's probably worth adding that some changes to Salesforce can effectively be staged and tested in production (via "Deploy Now" or hidden tabs) and do not necessarily require a sandbox.

Yet another possible exception :-)
Mike Leach
Tuesday, 23 November 2010 10:41:18 (Pacific Standard Time, UTC-08:00)
Great idea, but why not build this matrix IN salesforce as a new custom object? Why not "eat your own dog food" as they say?
Tuesday, 23 November 2010 11:12:36 (Pacific Standard Time, UTC-08:00)
Good idea. This currently warrants a static Visualforce page in our org, but not quite a dynamic "app" yet.

Mike Leach
Tuesday, 23 November 2010 11:18:28 (Pacific Standard Time, UTC-08:00)
I'll follow up with a blog post on how SVN and Ant migration tool can fit into this process.
Mike Leach
Comments are closed.