Salesforce Admin Hack: Temp Fields

I ❤ temp fields! Temp fields are simple text fields, used mainly by administrators (though I have given access to superusers on a few occasions), to quickly and temporarily tag records with dummy text so you can easily locate those records later in a Salesforce report, an Apsona filter, in Demand Tools‘ Single Table Dedupe, the Apex Data Loader, or anywhere else where you can filter a Salesforce field. Here are a few ways temp fields can be useful and make you an even more #AwesomeAdmin.

To test out the examples below, start by creating your temp field. The examples below are on the Contact object but you can create a temp field in any object where it might be useful. Call it whatever you like as long as you know where to find it (“Temp Field,” “Temp Field 1” if you have more than one, etc.). Make it a simple text field, 50ish character count. Make sure that you make the field read-only for all users aside from those who should be updating these fields.

Tag a Group of Records for Easier Reporting

Let’s say a user has given you an Excel spreadsheet with a list of Salesforce IDs, or email addresses, or phone numbers, or names. Maybe the spreadsheet has IDs, maybe it doesn’t. The user wants to be able to run a Salesforce report on these people: their donation history, campaigns they are a part of, etc. The problem is, no Salesforce report filters will be able to match this list exactly because it was generated by the user, or because they took an old Salesforce report and deleted some contacts and added some new ones.

If you have the IDs: make sure the temp field you created is available in Apsona by clearing your cache after adding the field. Next, add a new column to your spreadsheet with the name of your temp field as the header. Choose any value for the field as long as it’s the same for every record. My personal best practice is to insert the date into the end of the field value so if I stumble on it later, I can remember when I used it, which will (hopefully) remind me why I used it and whether it can be cleared or overwritten. Your spreadsheet will look something this this:

TempTest0719

Copy and paste into Apsona like you are doing a record update – all you are doing is updating this one field. Afterwards, add Temp Field = TempTest0719 (or whatever your value is) as a filter in any Contacts report, and send to your user. Once you are done, clear the temp field or just leave it alone until you need to make your next update – with your next update, you’ll simply overwrite what’s already there. (that’s when having a date in the value comes in handy). See below regarding clearing the field.

If you don’t have the IDs: don’t forget that in Apsona, you can map on more than just Record ID: you can also use email, name, name in combination with address, and more. You can follow the same process as above with what you have, or if you have a mix of those different things, run each one through Apsona separately and use the backup file, which contains IDs, to do your final upload.

Merge records with Demand Tools

If you have used Demand Tools’ Single Table Dedupe function, you know it can be confusing and slightly terrifying (am I sure I want to merge all of these records with no backup??? No, not when you say it so ominously!). The UI is not the best; if you’ve pulled in the wrong fields to review, you have to keep adding them afterwards; it’s difficult to look at all the data you need to look at at once to make an informed decision about whether you are merging the right records or not; you can’t find the scenario you were working on last week, etc. Or maybe you already have created a complex Salesforce report, exported it to Excel, and don’t feel like going through the steps of carefully re-creating all of the conditions in Single Table Dedupe’s UI. For whatever the reason, I have often found it easier to review this data in a Salesforce report, either within the Salesforce UI or exported to Excel, where you can sort and filter. My favorite way to safely merge records using Single Table Dedupe is with a temp field. Once I have finalized my list of records that I want to merge, I’ll do similar to what you see in the example above, but I don’t put the exact same value in the temp field. Let’s say I’m merging contacts: my temp field upload might look something like this:

TempTestMergeRecords0719

My temp field value starts with Merge0719 but has the last name of the contact appended. Once I am in Single Table Dedupe, I can simple add a condition in step 1: Temp Field starts with Merge0719:

SingleTableDedupeFilter

Since you have already done your work in Salesforce or Excel to determine which records you want to merge, your only mapping condition in Step 2 (selecting fields to match) will be your temp field:

SingleTableDedupeMap

On the next screen, your records will display grouped accordingly. From here, determine your master rule to tell the system how to decide which record should be the master, test one to start and verify that the merge went as expected, and then do the rest. Clear your temp field from the master record after you’re finished.

Clearing a Temp Field

My best practice is to clear a temp field after I’ve finished using it to avoid future confusion. Create an Apsona filter Temp Field = your value, and update all records in the filter to Temp Field = blank. You’re finished!

There are countless use cases for temp fields, especially with Apsona and Demand Tools at your fingertips. Apsona, in particular, makes updating records such a breeze that I use temp fields multiple times a week. Do you use them? If so, please share your use cases!

Advertisements

Making the Case for Documentation

It seems appropriate that my first post on this new blog would be about documentation. How meta! When I say documentation here, I’m focusing on documenting what’s happening in the setup menu for the benefit of anyone searching or trying to make sense of administrative settings, though much of this applies to different kinds of documentation.

I have thought about this topic so many times since starting at my most recent job as a Salesforce Administrator at Year Up, a large nonprofit organization with 600 (and counting) active Salesforce users and a dedicated team of 7 working on current and future Salesforce functionality. Why is documentation so important in a Salesforce setup environment?

Perhaps the most obvious: no one knows exactly what you’re doing or why, except you

None of us works in a bubble, even when we are a rockstar solo admin. If we rock enough, we’ll head off to a bigger, brighter organization after some time. And someone’s going to have to know why you did what you did.

Sometimes even you don’t know why you did something

Right in the moment you think, this makes total sense! And I need to do this task and move on so I can get on with my busy day. And some time later, you stumble on that same formula field and cannot remember why you put it there. This morning my co-admin asked me why I created a particular Public Group six months ago. Now, I remembered creating the group, and I remembered that there was an actual reason for it. I went digging through the helpdesk ticket archive, sharing rules, report folders. Nothing. Oops. Could have prevented this one, easily, with some simple documentation.

Nonprofit Salesforce setup can be complex

When you’re building custom fields, workflows, validation rules, and processes that are specific to your organization’s mission, program, and business processes, things that start off seeming fairly obvious can get obscure pretty quickly once you’ve gathered your requirements from your staff and started building. Furthermore, if you’re paying a developer write a trigger for you, or you’re an #AwesomeDeveloper and are writing it yourself like a rockstar, I can tell you for certain that no one knows what that thing does besides you. And I’m sure it does a lot of cool stuff, because it’s custom coded.

Data is flying in from everywhere!

Where did this data come from? Was a big mantra at my last system administrator job. We had data generating and updating from webforms, a gift processing vendor, custom apex code, and the Rollup Helper application, not to mention from our own users. If you have a field only being updated by one of those groups, put it in the field description! We incorporated this as standard procedure for adding new rollups. The description would read something like:

Populated by rollup helper {insert link to rollup details here}.

Simple as that. That way, when you, a fellow administrator, your successor, or anyone else with admin access goes into the setup menu to understand what the field means, they can find out easily and quickly.

So why is it worth our time, and therefore our money, to do this?

The short answer to this one is that a little bit of time invested at the beginning can save hours of time later on. Not prioritizing documentation is taking a short-sighted view of Salesforce implementation and maintenance. Helping yourself – or your coworker or successor – remember or understand what you did can prevent the frustration and time of digging through the setup menu for an afternoon, running 5 reports, calling vendor helpdesks, deleting something important (because no one understands its importance), or reinventing the wheel by putting something in the system that might already be there with a different name but no description.

But I’m using a consultant, and they’re doing all of our buildout for us!

The case for documentation might be even stronger if you’re working with an implementation partner. They’re building stuff for you – make sure they give you some documentation for what they did, and why! It will likely save you hours of time and headaches later. Remember, Salesforce implementation is an ongoing process, not a one-shot deal. The more your consultant documents, the less likely it is that you’ll have to call them again and again to ask questions or modify something after the solution has been implemented.

Where should I put it?

Anywhere where it will be easy to find, search, and update. Use description fields everywhere you go and make it a standard part of adding any new field, workflow, validation rule, etc. If we’re talking lots of complexity, like a custom object, use Salesforce Solutions! Start a wiki! Use your organization’s intranet, if you like it and it meets the criteria above (easy to find, search, and update). Start a Word doc or a google doc!

Last tip: documenting does not have to be wordy or complex. Outline the basics of whatever you built. Your reader will thank you for your brevity – because it will make their job easier. And with that, happy documenting!