Tracking Salesforce Changes: The One Custom Object Every Org Must Have
When stepping in to a new org, we’re often missing the most critical piece of the puzzle: context. Have you ever stepped into a new org, and thought, “What the heck were these people thinking?!”, or, if you’re diplomatic, “What an interesting way to set this up”. Having a method of tracking Salesforce changes directly in Salesforce is important to the health of every org.
A new admin often has next to no information on how or why somethings were done in a certain way. Even when the prior person is available to answer questions, they certainly don’t have every reason behind changes memorized!
Or, maybe you’re not a new Admin/not new to your org but your email inbox looks like this:
As your org and your Admin team grow, tracking Salesforce changes becomes critical. This brings context and stability to your org for the long term. For example, you will be able to understand why a particular field was added, who requested that automation, and what the original intent was.
This information is a huge help when you’re doing future enhancements, or deciding what needs to be cleaned up or removed. Having this log will allow you to ‘time-travel’ back to when you made a decision, and why. You’ll be able to understand the impact of that change over time, and be able to make more accurate, well thought out changes in the future.
This guide will show you how to create your own custom Salesforce tickets object for users to submit requests, and for you to track your changes.
Step 1: Create a Custom Object
Get started by creating your custom object. Ensure that you:
- Allow reporting: You will eventually want to create reports and dashboards based on your Salesforce tickets.
- Track field history: You need to know the history of most of the fields on this object.
- Allow search: To find these Salesforce tickets again later.
- Auto-number naming convention: It’s easier to reference a Salesforce ticket number in reports, dashboards, and descriptions.
Step 2: Add Custom Fields and Arrange the Page Layout
Here’s an example table for planning the custom fields. Tailor these fields, values, and requirements to your business:
Below is an example ticket page layout. My bonus tips include:
- Customize your highlights panel to see key information at a glance.
- Read only fields: You may want to make some fields read only for your regular users, and editable only to Administrators.
- List out both your standard and custom objects in the “Primary Object” picklist.
Step 3: Build Automation
- When a ticket is created, assign it to the correct user. Send an email to both the creator, the requester, and the new owner.
- When a ticket is completed, rejected, or canceled, populate the Completed Date. Send an email to the requester.
Step 4: Create Data and Reference Points
- Create a dashboard for tickets completed per team, tickets completed over time, current open tickets by priority, etc.
- Create list views for yourself, such as High Priority Tickets, New Tickets, all Open Tickets, Tickets due this week, etc.
Step 5: Training and Accessibility
Ensure it’s easy for users to fill out these Salesforce tickets by creating a training document, and holding training sessions. You could take this enablement one step further with in-app guidance. Add this new object to your Salesforce apps so that users can locate the tickets tab.
- Adoption: Obviously, this tickets object doesn’t work if you don’t enforce it! At first, your users won’t always remember it’s there, and won’t be in the habit of using it. Start replying to every email and verbal request with, “Did you create a Salesforce Ticket? Please create a Salesforce Ticket and I will get started on your request”.
- Description fields: There’s a place for a description in many locations in Salesforce – Validation Rules, Flows, Approval Process, Custom Fields, Change Sets – the list goes on. The description field is the perfect place to identify why you’re adding this feature. Even just copy-pasting the Salesforce Ticket number gives you and all future admins a reference point for this feature.
- Use Chatter or Slack: Having a communication log directly with each ticket adds color to the reasoning behind each enhancement, and helps future users understand why a change was made. You also ‘protect your back’ if a user claims you didn’t build something exactly to specifications.
We already have Jira. Can’t I use that instead?
Sure, you can, but there are drawbacks. The admin has two work in two systems, or has to manage an integration between the two. You might not have Jira forever, and it’s possible that not all of your Salesforce users are also Jira users.
Having this object directly in Salesforce is the fastest, easiest, and most comprehensive method for your users and administrators. As long as you have Salesforce, you’ll have a permanent record of your changes, too.
Ok, but do I really have to create a custom object? Can’t I just use the Case object?
Again, sure, you can. But keep in mind, your job as Administrators is to make Salesforce easy and accessible for your users. The Case object has been used by many organizations by creating a Record Type for internal tickets.
You and your users are not going to enjoy adding a Record Type filter to every single Case report, for example, you’ll have to repeat the phrase: “You forgot to filter out the Salesforce tickets from your Case report” to every customer service manager.
I’m too busy to create this.
I hear you – and that’s ok, there’s an app for that! Our friends at http://www.tysoapps.com/ have a pre-built, ready to use tickets application that you can begin using today. Or, just search “Change Management” on the AppExchange.
Show Your Admin Value
It can be incredibly challenging to demonstrate your value as an admin (especially a solo admin). Having a log of requests that you have completed demonstrates and documents your value to the management team and your peers.
Here, I can show my manager that the new training that I provided to all users had a direct, positive impact to the number of Requests created quarterly. This increased user satisfaction and reduced the amount of “admin hours” spent on non-essential tasks.
This guide has showed you how to create a very basic Salesforce tickets object. In an hour (or less), you can have a repository for every change you made in Salesforce, and why.
You can take this further by adding time-based reminders, an Approval Process, or even projects that contain multiple Salesforce tickets.
In just a few weeks, you’ll notice your completed Salesforce tickets start to pile up, your reports and dashboards filling out, and your team starting to recognize the great work you do. After you’ve been working in this org for a few months or years, you’ll have a fully baked org history that will be invaluable to the org’s future growth.
I like this – not too complicated, but can provide great value. Thanks for sharing!
There may be cases where this is the best approach.
However, in an organization like ours, with an established help desk and using Service Now as the ticket system, and lots of applications, it is actually easier for all to use the single established incident reporting system for all systems. and we do use Jira to manage work because, again, we have teams who support many applications, not just Salesforce.
Or use Elements.cloud that has build a sophisticated requirements management capability as part of suite of implementation tools so you get traceability from requirements (integrated into JIRA), through process design all the way to Salesforce config documentation…… so you get 100% traceability.
Hi Ian, do you have any article/video that describes how to use Elements.cloud for creating change logs? Thanks!
Excellent Idea ..
I disagree with your suggestion that using cases for internal admin support will make it less clear for the end users. I run an org of 300 users with high adoption. Email to Case and the built in support for Case Escalation cannot be replaced with a custom object without a lot of forethought.
I recommend Salesforce Admins use cases. The concept is different however, as cases are related to contacts, using email to case requires that you also maintain a contact record for each user in your org. (Which I do).
I have ONE record type for my team. So the users who do use cases, are not disturbed by a long list of record types. I’m not sure I understand where you were coming from when you wrote this. Cases are awesome.
Quick note on this comment – this only applies if you have Service Cloud enabled for your organization. We run a very small operation and haven’t enabled Service Cloud purely due to cost (when you run an organization with less than 30 people, it’s hard to justify an extra $13-15k/yr for cases).
What Ben describes in this article is a nice alternative feature if you don’t have Service Cloud. It’s free (mostly – just paying for data records which is nominal), it’s simple, and it works. We use a similar custom object in our system to track requests for changes.
Ross Bradley Bixler
I agree with you. I use the standard case object for change management in Salesforce. Case Record Types are naturally going to be necessary for most orgs anyway. I disagree that it’s necessary to maintain a Contact for each User in your org simply to leverage email to case. Since the from email address is captured in the “Web Email” field on cases created via Email-to-Case, you can easily create a flow that lookups the user and relates it to the case. I created a Lookup field on Cases to the User object called “Requester” (as suggested in the article) and populate it via flow. Conversely, you could also easily create a flow that manages the creation of a Contact for each User. To each their own!
Hi Troy, what would you suggest if the org as multiple admins and developers making the changes? Would Cases be useful to track those changes? If so, how?
I disagree – defaulting for email to case for internal project management opens up a myriad of issues down the road… some day you may find you are now with 200 service addresses and an extremely convoluted case object. And with email to case specifically, people get lazy and just send an email, when they can/should just go create the case directly – it supports bad lazy behavior AND will eventually start to suck up all your data storage.
Cases are great, email to case functionality is awesome – but internal work management can often be better served by custom objects.
Not finding the Tyso app on Appexchange, do you have a direct link?
Hi Brian, you can email [email protected] for more information
so happy to see this! it was already on my to do list for next week.
I definitely agree with Troy Center. Not sure what the use case is to create a new custom object. When you can set up a SFDC admin case RT and go from there.
In newer, smaller orgs, or with new Admins, or Admins with no other choice besides Salesforce – the options might be Salesforce, or nothing, and I personally believe Salesforce Tracking is much better than nothing at all, and can, in a lot of cases be better than an external system. This solution is very simple for an Admin to implement, and requires zero learning of an external system. The records will always be around, as long as the customer always has Salesforce.
@Tony – I do agree that Cases are awesome- for external Customer Support. My clients usually use Service Cloud and implement Email-to-Case for their end customers. And with tens of thousands of CS Cases, I do not want a CS Manager to have to add a “Record Type not equals Salesforce Ticket” on every report they create. It’s easier just to use a second object, because the CS Manager would never have a reason to report on Salesforce Tickets. Also, with a limited number of fields, workflows, and validations on each object, I prefer to save those for the Customer Support and customer facing cases, rather than use that up with my Salesforce Tickets.
I like this method because:
-no purchasing or installing external applications
-no building out integrations
-no conflating the difference between an actual external ‘customer support’ case, and an internal ‘Salesforce Ticket’
-can be implemented quickly by an inexperienced admin
-no extra cost
-provides history, reason, explanation, on all changes that were made
It’s not the only solution out there, certainly, but it is a great option to consider.
is there an example of the automation?
This article needs to be updated. The link to Tyso apps Tickets application at: http://www.tysoapps.com/ does not take us to any app. You posted a Tyso email contact for a previous comment from @Brian Murphey. However, it would be better to update the article.
Searching “Change Management” on the appexchange returns no useful results.
For my instance, which is a force.com platform app and doesn’t have access to the Case object, this is perfect. We are a small company and don’t do any custom app development beyond configuring this app so this will help us document what we need to stay sane.