By: David Taber
Salesforce administrators are responsible for tasks ranging from helping users develop reports and reset passwords to maintaining data quality, adding fields, and running backups, among many others. Those ad-hoc tasks do not a job description (or MBO checklist) make, so here’s a look at what admin tasks need to be done – and when.
Let’s start at the beginning: just because Salesforce is in the cloud doesn’t mean that it’s not a core IT asset. You don’t own the hardware or the software, but the data you hold in Salesforce is typically much more valuable than your Salesforce.com (SFDC) fees. Further, the productivity increases from sales, marketing and support dwarf the inherent value of your CRM data—that’s why it was worth investing so much in SFDC in the first place.
Happy, productive users depend upon the system infrastructure and data quality, and that means the system admins can’t be haphazard.
Let’s tackle the best practices topic from two angles: what needs to be done, and how it needs to be done.
The lists below summarize which tasks need to be done at standard intervals, including a pro-forma time budget. While the terminology and specifics focus on Salesforce.com specifically, the general administrative principles apply to any modern CRM system.
Real-time Salesforce admin tasks
Administrators will occasionally need to resolve user problems in real time. A report may not run this week, or a process may break in mid-stream. Expect to devote two hours per week to these activities for every 100 users you have:
Unlocking user accounts or resetting passwords due to user forgetfulness.
Dealing with SSO, two-factor authentication, and certificate problems.
Adding new white-listed IP addresses.
Helping users develop or fine-tune reports so they yield meaningful metrics
Troubleshooting email campaigns, workflows, approval cycles, or auto-responders that generate excessive bounced mails.
Expanding or refining sharing rules and access privileges so records can be properly viewed and manipulated (while keeping the “special records” locked or hidden altogether).
Fixing data records that have somehow been set with record types or ownerships that make them inaccessible to users.
If your execs are very attentive to details, budget another 30 minutes per week for each VP that an admin has to cover for reports they didn’t receive, don’t understand, or don’t believe.
Weekly Salesforce admin tasks
Many duties seem to follow a weekly cycle. A lot of things that were working fine last week will go wrong Monday morning-don’t ask me why. A couple of tasks also need to be done once a week on the day of your choice. Overall, these tasks require two to six hours per week. Keep in mind, though, that’s just an estimate for a relatively straightforward system. If your environment has to serve a dozen different user groups and tons of use-cases, the weekly stuff can easily exceed a day or more.
Run and store the weekly snapshot (data export) of the system data and attachments, including all history tables. Keep the snapshots for at least 90 days (and preferably, for years).
Run data deduplication tools such as Ring Lead or DemandTools. (These are dangerous if not used correctly, though, and their Uls are clunky at best. Read your tool’s user guide as well as our comprehensive guide to deduping in Salesforce.
Run adoption dashboards.
Run data-quality dashboards.
Examine time-based workflow and scheduled APEX queues to make sure there are no unexpected entries.
Examine SFDC error and debug logs for any surprises. For any external application that synchronizes data with SFDC, look at its error logs to see if a new error pattern has developed.
Look at the login history table to spot any user lockouts, excessive login errors, and unexpected IP addresses.
Deactivate users—either due to their departing from the company or transferring to a new job that does not require SFDC access. Reassign roles and profiles as needed to reflect organization changes or users’ new duties.
Transfer record ownership due to changes in job responsibility or territory coverage.
Modify roles or record-sharing rules to reflect any organizational changes or internal business rules.
Import leads and contacts.
Update price lists as necessary, particularly if your company does a lot of promotions and limited-time offers.
Change delegation and escalation paths in workflows and approval cycles to account for absences or extended travel.
Run all APEX tests in the system to spot any new errors that may have crept in due to “harmless” changes in validation rules, triggers, or data “cleanup.” Navigate to Setup > App Setup > Develop > Apex Classes and push the “Run All Tests” button. It may take an hour or more for this to complete, but if you find any new test failures, log them in the system wiki/Google Drive area and troubleshoot. Some failures may go away if you push the “Options” button and click the “Disable Parallel Apex Testing” box. You may have to file a case with third-party vendors (check Setup > App Setup > installed Packages), but that usually starts a finger-pointing exercise, so make sure you have your act together first. Causes of new test errors include the following:
New validation rules that fire.
Changes to workflow rules, particularly when they change field values or generate outbound messages.
Modified pick-list values or record types (including renaming)
Changes to the security model that make some things inaccessible to code.
Changes to the software modules that blew up.
Open up the Setup Audit Trail and look for any changes/adds/deletions made in the last week. If you made them, make sure that there is some form of documentation/annotation in the actual area you made the change (e.g., the Description on fields, comments in any formula, comments-in-the-form-of-neuter criteria in any rules or filters (see How to document in the cloud for further info on this). For changes you did not make, talk to the person who did and get them to document the change (including the reason for the change and who the requester was). Nobody will remember why changes were made 6 weeks from now, so get the changes written up while you still have a clue about them.
Run Eclipse and take a full system snapshot of your production system metadata. Archive each snapshot as a new project, so you can run diffs later.
Look in the Duplicate Error Logs to see if there has been a significant change (read: explosion) in the duplicate detection. Big changes indicate you may need to reformulate some of the duplicate matching rules.
Look in the Delegated Authentication Error History log to see if there has been a ton of new errors. Big changes to the error pattern indicate some misconfiguration in external access.
Monthly Salesforce admin tasks
A few activities can only be done once a month but nonetheless need to be done more often than once a quarter. In all, this monthly cycle will take one or two days’ effort.
Isn’t it time for a fun way to drive? Own a 2017 Mazda CX-5. Find available models here.
Explore the specs, trims and features of the all-new 2017 Mazda CX-5.
Make additions and changes to pick-list values and other fields. It’s important that these kinds of metadata changes not be made on the fly, as innocent changes can have surprising effects on system behavior. It’s best to pre-test prospective changes in a full sandbox.
Run field utilization reports to identify any new sources of data pollution. If fields are consistently blank more than 30 percent of the time, consider removing them from page views and see who complains. If a field is consistently blank 95% of the time, consider deprecating it altogether (but don’t remove it from the system — just mark it as deprecated).
Before refreshing the sandbox(es), use Eclipse to make a complete metadata backup of the sandbox images and your main system image. Create a new “project” every time and archive them for at least a year. You’ll thank me when somebody starts badgering you about a report deleted four months ago.
Refresh the sandbox(es). Coordinate the timing of these updates with the work of any developers who are using the sandbox, lest you blow away some of their work.
Read about high-priority fixes from Salesforce.com. These fixes will be installed by default within a few weeks, but it’s better if you do the patch installs when you have time to pre-test, react, to and fix any problems you discover.
Install the high-priority updates that may have been pushed into your Salesforce.com instance. It’s best to rerun the “run all tests” exercise after enabling the updates. If something goes wrong, disable that update and notify the relevant vendor(s) of the issues.
Create an archive copy of any error logs kept in your integration server and any connected applications.
Run a full system backup (data, metadata and error logs, if possible) on any system or application that is integrated with Salesforce.com.
Compare the current “CustomSettingNameIndex” from this week’s data export with the contents of last quarter to identify any new or deleted custom settings (that’s the object, not the data in the object). Figure out why the add/delete/rename was done and document it somewhere.
Now that you have the names of all the custom settings, compare the current Custom Settings metadata to the exports of the prior quarter’s metadata in Eclipse to spot any differences in the object definitions. If the custom settings object does not have a “notes” field, add it in the production system and put any metadata change annotations there (this has to be done manually).
Run Data Loader (or your favorite data extraction tool) to pull out the custom settings data, and compare it to the corresponding files from the previous month. Annotate any changed records by editing the changed ones in the production system (this has to be done manually.)
Look in the Email logs to identify any egregious use of email through Salesforce.
Quarterly Salesforce admin tasks
There are a lot of items in the following list that will occupy you for one to three days per quarter. However, the first two are mission critical, and the resulting files should be kept forever. You’ll thank me when a pesky plaintiff attorney goes into a discovery process on Salesforce.com data.
Add or remove members of your Communities or Partner Portals, then download the CSV from the user login history.
Download the CSV from the system administrator setup audit log.
Read the release notes for any third-party application or plug-in connected to Salesforce.com. Typically, changes and upgrade cycles will be harmless, but occasionally several configuration and operational changes will be required as a consequence of external changes.
Run the Reports report to identify reports that haven’t been run in six months. Hide them from users, but don’t delete them.
Run the Roles by Profile Report to identify which roles or profiles have no active users in them. This identifies candidates for consolidation.
Examine any new pick-list values that have been modified or added to any fields in the system, and using the Force.com IDE’s Search function to identify the impact of those changes across all the Booleans, formulas, and APEX/JavaScript/VisualForce code in the system. Correct any elements that have been impacted.
Run Field Trip and EasyDescribe on all tables. These two free tools give you an overview of the health of your system’s object model.
Read the release notes for the upcoming version of Salesforce.com to see if any of your existing features or APIs you depend on are being deprecated or changed significantly. If so, you need to test the pre-release features in your sandbox and do the “run all tests” exercise there. It’s getting increasingly common that code, formulas and buttons need to be reworked to accommodate version changes.
If you’re a certified SFDC administrator, study (hours) and take (minutes) the admin recertification test. This is typically a 5-question, multiple-guess online test.
Attend at least one local Salesforce.com user group meeting or webinar. You’ve got to keep current!
Archive (please don’t delete) weekly data snapshots that are more than 90 days old.
Annual Salesforce admin activities
The main responsibility here is to capture data that will fall “over the horizon” or need to be archived for compliance reasons. These tasks will take three to six days per year.
Create an archive of all the system’s field history tables (typically spanning no more than 18 months) to ensure that you have an audit trail that goes beyond a year.
Archive or purge documents (in all four places where SFDC hides them), emails and tasks to reduce the storage charges in your system and to adhere with your company’s document/email retention policies.
Archive Chatter histories for audit, compliance or regulatory reasons.
Update system road maps that summarize upgrades and new feature additions that are needed to achieve business goals.
Attend DreamForce.
Of course, the time you have to spend on these activities will vary…and you’ll get better at it as time goes on. If all goes well, everything outlined here will occupy no more than 19 work weeks, leaving you plenty of vacation time. Uh-huh.