If I had to guess, your inbox is cluttered with emails from users asking for changes to Salesforce. Also, your desk is covered in sticky notes with the same content. More than likely, you also have a paper and digital notebook full of requests from users.

Total disorganization and no way to prioritize. It's ironic that we have at our disposal an application like Salesforce yet we as System Administrators don't think to use it - or we don't know where to start.

Change management is an extremely abstract topic for a lot of people (including myself). It has taken me a couple of years to fully wrap my head around what change management means to me and how to manage change. Today, I am going to explain why you need a change management process (for those who are not yet convinced) and how I am managing change requests within my organization.

What is Change Management?

Because this can be an abstract topic, let's define change management. MindTools defines change management as

...a structured approach for ensuring that changes are thoroughly and smoothly implemented, and that the lasting benefits of change are achieved. The focus is on the wider impacts of change, particularly on people and how they, as individuals and teams, move from the current situation to the new one.

With this definition, it is easy to see that change management is not so much a to-do list or a set of rules to follow, but instead, it is a method which aims to help users embrace the changes being implemented.

Change management can take many different forms and depending on the size of your company; there may be an extensive process that needs to be created and followed whereas smaller organizations may just need visibility to what is being requested.

The point is that this does not need to be complex.

Objections

Okay, at this point, there may be some objections to implementing a change management process. Before we get into more details, let's address those because this is such an important topic, I don't want you to think you can't do this.

I'm a solo admin and don't have time

I've been a solo admin as well I know that it is hard to juggle everything being thrown at you. There are a lot of things you would like to implement, but there is just no bandwidth. I understand. But I would venture to say that the amount of time you're spending today trying to manage these requests is make up a decent percentage of your bandwidth issues.

Your current process isn't sustainable. It's time to upgrade your process and make life easier on yourself.

I don't have experience with change management

Well, this is an easy objection to address because I am going to show you specifically how to set up a change management process which you can tweak and modify to fit your business. Consider it a template; a starting point.

Now that we have some of those objections out of the way let's get down to it!

Create a Request Form

First, we need to create a form in Salesforce to capture the requests coming in from users. This form will replace the sticky notes and emails and make you a far more organized and efficient administrator.

Cases would be a great place to create this form using a new record type and page layout. The administrator before me created a new custom object to track these requests. Either one works - just determine what will be better for your users and the organization.

Fields to Include

There are some basic fields to be included in this request form. In addition to the basic fields, you may want to add some company-specific fields as well. Look through the requests you have been working on and see if there are any patterns to the missing information and add fields to capture that information.

Here are some of the fields we use on our request form:

• ReadyTalk Team - a picklist that includes all of the teams in the organization. This allows us to track the number of requests by a team to understand volume and request types.
• Request Type - a picklist that classifies the request. Values include Workflow / Validation Rules, Email Template Creation / Modification, and Reports & Dashboard among others.
• Status - this picklist helps me and my team prioritize the requests coming in.
• Subject - a brief overview of the request. We use this in list views and reports for quick reference.
• Request Details - a large area text box where the requesting user adds all of the details of their request.

There are several additional fields that I didn't include above which you can see in the below screenshot.

Once the fields are added for the request, you may also want to include some fields specifically for your use. We found that there were several items we wanted or needed to track as we were working this request. Those fields include:

• Salesforce Case Number - if we needed to open a Salesforce case for this request, we wanted to be able to track which cases are tied to specific requests.
• Date Completed - we use a workflow rule to auto update this field when the status is marked as Completed. It helps us do some general cycle time reporting.
• Administrator Notes - this is a place to enter notes related to the request. Typically, I use this to specify any additional requirements or important notes pulled from email or Chatter communications.
• Time Spent - a number field which allows us to enter the estimated number of minutes spent on the request. We use this to get a general feel for the amount of time spent servicing various departments or specific request types.
• Resolution - we enter the resolution to the request into this box. The information contained here will be sent via email to the requester when the case is marked as Completed.

Here's a screenshot of the second section of the Admin Request page detail.

Remember, these fields are just suggestions. Create fields that apply to your business and the processes you support.

Once the form is created, also consider creating a Chatter Publisher Action to make the creation of a change request more efficient for users.

Build Workflow & Validation Rules

Now that the form is built consider creating some workflow and validation rules to go along with the new record.

Here are some examples:

• Record creation notification - send an email or Chatter message to the admin when a record is created so that it can be triaged.
• Completed notification to requester - when the request is marked as completed, send an email to the requesting user letting them know that the request is closed. Include the Resolution details in the request.
• Use a workflow rule to update the Completed Date when the record is marked as complete.
• Create a validation rule to require a business case when the priority level is critical.
• Use a validation rule to require the Why do you need this field to explain the rational on certain Request Types.

Deploy, Train & Enforce

If you build it, they will come doesn't work for this new piece of functionality. Users will not automatically begin logging these requests.

Notify users that the new request process is in place and requires that all requests come in through an Admin Request. This will be a bumpy road for a little while, but once you force users into the new process, they become used to creating the form.

We eased our users into the form over the course of a few months. In some cases, we created the form for users. But, we slowly weaned them off of their old habits and now require that all requests to our team get submitted through Salesforce. In fact, users now ask us if we want to have an admin request submitted to complete a task discussed in a meeting.

Use Chatter to Communicate

Chatter is a great communication tool. Now, instead of email, you and users can ask questions and post updates right on the record's Chatter feed. This has been helpful for my organization as it keeps the conversation in one place and ensures that the conversation can be kept within the context of the request.

Consider also activating Chatter feed tracking for additional insights for users that follow the record using Chatter.

If Chatter isn't enabled for your org, it's probably time to reevaluate that decision.

In Part 2 of this series, we'll look at the benefits of creating scheduled releases and how to use the admin requests to drive metrics and conversations with stakeholders. Click here to read Part 2.

What do you think of this process? Do you have any additional tips or tricks that work for your organization? Let me know by leaving a comment below!