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.

Admin_Request_Details

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.

SF_Admin_Request_Section_2

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!

 

35 thoughts on “ Creating a Change Management Process: Part 1 ”

  1. Great post, I wish I had known about change management years ago when I was first starting out as an admin. We currently employ a very similar model with similar fields. It was actual this process that helped drive Chatter adoption across the org, increasing its use among other objects as well! Now, when the boss asked what you’ve been working this quarter, you have an easy way to show how busy you’ve been (and all the value you bring!)

    Like

    1. Thanks for the comment Dan! It’s amazing what can be done with a change management process. We are just getting into the reporting aspect ourselves, but we hope that we will be able to see (and show) how productive our team was and show that to the organization. Thanks for reading!

      Like

  2. Great article. Our organization is just beginning a change management process. We are using the Ideas object to do so. We have implemented several of the fields you’ve suggested here and have hidden the admin-type fields to only the change management users. My next endeavor is to create the validation rules and workflows to do what you mentioned. Specifically, the completed notification to requester. I have no idea how to do this, but I’ll figure it out, I’m sure! We also want to post to Chatter when an Idea is implemented (status field gets updated to implemented). I don’t know how to do this either. I have lots to learn!

    Like

  3. Happily working through your exercises on a sunny Saturday Brent!

    Questions about the workflows you mention above: won’t these trigger on all cases? I want them to only fire on this new page layout, is that possible. One reason is that I personalized the new email template (for when the status is marked as completed) with the user name and message ‘Your change request is done!’. Maybe I need a custom field for status that only goes on the Change Request page layout?

    Also, process builder or workflow? I reviewed ‘Which Automation Tool Should I Use’ and it seems PB is better for everything except ‘actions to be executed at multiple intervals’. I used PB for 2 and workflow for 1 to practice.

    Appreciate your help!
    Kevin

    Like

    1. Hi Kevin! You are correct, workflow and validation rules need to consider the record type otherwise they will be evaluated for all records in the object. I like to create a record type for each page layout. This allows me to easily create the appropriate workflow and validation rules and manage picklist values. You can find out how to use record types in validation rules by clicking here: https://success.salesforce.com/answers?id=90630000000h0D0AAI

      In terms of Process Builder vs Workflow Rules, I would say either one will work. Process Builder is the obvious choice if there is some complex logic, and it is the way in which Salesforce is moving. However, workflows still work just as well. So really, it’s up to you! I hope that helps!

      Like

  4. Oh and one more: when creating something like this there are 3 parts, yes?: custom fields, page layout, record type. What is the best order to create these? When I try it always seems I started from the wrong one because they are all connected and after I create one I’m supposed to apply or connect it to another which isn’t ready yet. After this post I’m done studying for the day!

    Like

    1. Hi Kevin! I have found that the best order to create these is page layout, record type then fields. Doing it this way will require that you update/edit the page layout once the fields are created but I prefer to have the page layout created and modify as I work.

      Like

  5. Update, got it to work with PB and the record type name ‘change_management’. All good! Not sure why they are voting up that idea.

    Like

  6. Hi Brent!

    Great article 🙂

    This info will go towards an app we are building that will encompass Project Management, Business Analysis, Change Management, Budgeting etc for a freelancers and SF professionals.

    Its in the works!
    I hope we can roll it out soon 🙂

    Take care.

    Regards,
    Jose

    Like

  7. Great post, Brent! I’m coming it late – I noticed you posted it back in January – but a change management process is something we’re planning on implementing here at my company in the next while, and this info will go a long way to helping us decide what to track. Thanks!

    Like

  8. Hey Brent – Was the Business Case a text field? I see you required it based on different Priority levels – was it just a quick description or something more involved?
    This is a great post I am using to roll out something similar in my org, thanks!

    Like

    1. Yeah, just a text field with a validation rule. The idea was to have the requesting user provide some context for the request. It helps them to think through the “Why” and allows us to ask additional questions to ensure we’re building the most appropriate solution.

      Like

  9. 3yrs later this blog is still helping-Thank you!
    I’m building out my Case object to capture user requests for Salesforce enhancements. How have you utilized the Contact Name and Owner fields?
    Contact Name is a standard field that you cannot remove from the page layout. Did you add all your users as contacts in Salesforce and used this field to communicate to the requested user?
    Did you use the Case Owner as the “assigned to” admin?
    Any experience and.or lessons leared with using cases to capture internal SF user requests would be appreciated! Thanks!

    Like

    1. Hey Jen! You can do a few things: ignore the fields (and move them to System Information or a different section on the page layout), or create Contacts for all users. The easiest is to just ignore them, even though they are annoying to stare at! The nice thing with this process is that it’s flexible. If something doesn’t work out well, just make an update to your process!

      Like

  10. Hey Brent the org i have inherited has implemented email to case and the service cloud console
    do you think change management will also help in any way

    Like

    1. Sure! Change management is all about how change is organized, prioritized, and executed. You can use Cases for internal as well as external items. Or, create your own object and manage it outside of cases if you think it would cause confusion. Good luck!

      Like

  11. Thanks for this Brent!
    I have been tasked with creating a change management process for my company within SF and this is perfect. They currently use Zube for it-but have found it it to not be effective.
    How long do you predict this takes to create? I am a new admin so I know it will take me a little longer than an experienced one.

    Like

    1. You could have this created in a matter of an hour or two depending on how complex you want to make things! Of course, there will be the ongoing maintenance and tweaking of the process, but the general setup shouldn’t take too long!

      Like

    1. Hey Rob! I actually don’t see that Chatter is fading away at all. It’s not being talked about as much as in the past, but it’s very much still alive. For example, Lightning Experience can’t be enabled without Chatter. It’s central to Lightning and it’s still very much a core component of Salesforce. Now, whether you’re using Chatter internally is a different question!

      Like

  12. What a great article! I’ve been trying to figure out how I want to do this as a solo admin and you’ve given me such a great example. By the way, before you forced users to use Salesforce to submit a request, did you create a web to case form? If not, how did you make it into a form?

    Like

      1. Hi Brent, I’d love to know how you created the form for users to use before you forced users to use Salesforce to submit a request. Did you create a web to case form? If not, how did you make it into a form? Thanks in advance for your time.

        Like

        1. We just used a simplified page layout and record type (from what I recall) but you could use a Flow with screen steps or something similar. You could create a web to case, but my users were all in Salesforce, so it made sense to have them create the request record directly in Salesforce.

          If you’re using Lightning, perhaps create a Global Action that would allow the user to create a request from anywhere in the org. Lightning provides a few great ways to create those records.

          Like

  13. Great article Brent.

    As a new admin in service cloud I start my job next week. Is there any checklist for first steps? May I review the sow and meet the users, understand the data model? What can you suggest me as first steps to start my job successful and structured?

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.