Tracking Salesforce Changes: The One Custom Object Every Org Must Have

Share this article...

Many of us have had the experience of stepping in to a new org, looking at all the changes that have been done, and thought, “What the heck were these people thinking?!” or, if you’re a nicer person than I am, “What an interesting way to set this up….” When stepping in to a new org, we’re often missing the most critical piece of the puzzle: context. A new admin often has almost no information on how or why things were done a certain way, especially when the person who did the set up is gone. Even when the prior person is available to answer questions, they certainly do not have every single reason, for every single change, memorized! Or maybe you’re not a new Admin, or not new to your org. Maybe this is your current org, and your email inbox looks like this:

Having a method of tracking Salesforce changes directly in Salesforce is important to the health of every org. As your org and your Admin team grow ever larger, tracking these changes becomes critical. This brings context and stability to your org for years, even decades to come. Years from now, you will be able to see why a particular field was added, who requested that piece of automation, and what the original intent was.

Having this information is a huge help when you’re doing future enhancements, or even deciding what needs to be cleaned up or removed. When your users start asking, “Why did we implement this change?” you will have a solid, documented answer that you can confidently deliver. If you, as the Admin, stay in your org for a few years, you won’t remember every change you ever made. 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. You will also reduce the amount of noise you deal with on a day-to-day basis, and will be able to manage your org’s priorities in a way that makes sense and is visible to your users and leadership.

This guide will show you how to create your own custom Salesforce Tickets object to track your changes

Create your Custom Object

Get started by creating your custom object. Be sure to:

  • Allow Reporting (you will eventually want to create reports and possibly a dashboard based on your Salesforce Tickets)
  • Track Field History (you need to know the history of most of your fields on this object)
  • Allow Search (you need to be able to find these Salesforce Tickets again later)
  • Use an Auto-Number naming convention (It’s easier to reference a Salesforce Ticket Number in reports, dashboards, and descriptions)

Add Custom Fields & Arrange Page Layout

  • Don’t forget to customize your highlights panel!
  • You may want to make the fields in the Administrator section “Read Only” for your regular users, and editable only to Administrators
  • Tailor these fields, values, and requirements to your business, and don’t forget to name your custom objects in the “Primary Object” picklist.

Create Automation

  • When a Ticket is created, assign it to the proper user, and 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, and send an email to the requester

Create Data/Reference Points

  • Create a Dashboard for Tickets completed per team, Tickets completed over time, current open tickets by Priority, etc.
  • Create a few list views for yourself: High Priority Tickets, New Tickets, all Open Tickets, Tickets due this week, etc.

Training & Accessibility

Your users are going to be the people filling out these Salesforce Tickets. Make sure it’s fast and easy for them to do so.

  • Create a training document
  • Provide a live training and record it so you can refer people to it in the future
  • Add this new object to your custom Apps

Best Practices

  • It doesn’t work if you don’t use it! A Tickets object is useless on it’s own; it doesn’t intuitively know what your users want. And your users don’t know it’s there, and aren’t in the habit of using it. Start replying to every single email and verbal request with, “Did you create a Salesforce Ticket? Please create a Salesforce Ticket and I will get started on your request.”
  • Everywhere you look in Salesforce, there’s a place for a description: Workflow Rule, Validation Rules, Process Builder, Approval Process, Custom Fields, Change Sets, the list goes on. That description field is the perfect place to identify why you’re adding a this feature. Even just copy-pasting the Salesforce Ticket number gives you and all future admins a reference point for this feature.
  • Use Chatter! 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. It can also protect you as an admin if a user claims you didn’t build something exactly to specifications.
  • Add the Salesforce Change Request Name (SFT-00000001) to the description box every time you create a field, workflow rule, validation rule, process builder, etc. This will help you reference exactly why this feature was created.

Some Questions I’ve gotten from implementing this in my own orgs:

We already have Jira. Can’t I use that instead?

Sure, you can, but there’s drawbacks to that. Your admin has two work in two systems instead of just one, or has to manage an integration between the two. Also, 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. And you and your users are not going to enjoy adding a Record Type filter to every single Case report they create from now until the end of time. And you’re really not going to enjoy repeating the phrase “You forgot to filter out the Salesforce Tickets from your Case report.” to every CS manager you ever speak to.

I hear you saying, “I get it, but I’m too busy to create this.” 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.

Special side benefit for Solo Admins: It can be incredibly difficult to demonstrate your value as a solo admin, especially if your leadership team is not made up of Salesforce experts. Having a log of things that users have requested, and you have personally completed, can be a great way to demonstrate and document your value to your management team and your peers. It makes you personally accountable, and allows you to show how many requests you have completed over time.

Here I can show my manager that my new, revamped training that I provide to all users had a direct, positive impact to the number of Requests created quarterly, which increased my internal customer satisfaction and reduced the amount of “admin hours” spent on non-essential tasks.

Conclusion

This is a very basic Salesforce Tickets object. In less than a couple hours, you can have a full history of every change you made in Salesforce, and why. Of course, you’ll need to tailor this to your business needs. And if you’re so inclined, you can add even more features like Time-Based reminders, an Approval Process for more technical requests, 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 and appreciate the great work you do every day. 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 org’s future growth.

12 thoughts on “Tracking Salesforce Changes: The One Custom Object Every Org Must Have

  1. Avatar

    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.

  2. Avatar

    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.

  3. Avatar

    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.

    1. Avatar

      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.

    2. Avatar

      Ross Bradley Bixler

      Reply

      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!

  4. Avatar

    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.

  5. Avatar

    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.

Leave a Reply