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.
- 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
- 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.
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.