Danine Pontarelli

Sugar Admin Best Practices: Managing Configurations

Blog Post created by Danine Pontarelli on Jan 10, 2019

As a Sugar Administrator, you play a major role in team productivity. If the CRM isn’t configured with fields and calculations that make data entry easy, the team isn’t going to use the system. In parallel, if the fields and calculations aren’t helpful, it will lead to frustration and wasted efficiency.


During our December online user group discussion, our Sugar experts addressed the concept of managing configurations and gave best practices advice for modifying dropdowns, deciding what to require, managing searchable fields, and more. I’ll summarize their points in this blog. Check out the video clip for their commentary, and join us for our February online user group where we’ll tackle using quotes in conjunction with opportunities, products, and forecasting.

Best Practices for Adding a Field

When adding a new field to your Sugar instance, it’s important to first understand how that field will be used. Will the information in that field need to be searchable? Will the user need to draw reports from it? Is it a calculated field? Think about how to best match the field type to fulfill the field purpose.


For example, it would be better to use a dropdown instead of a text field if the user wants the ability to easily report on the data. Why? If you use a text field, you are leaving the spelling, punctuation, and capitalization open to human error, which will make it that much harder to accurately draw a report.


Need to do a calculation on a value? Use an integer or currency field so you can add, subtract, or average those numbers in a calculated field or summation report.


When adding a text field, make sure you think about character length. What will you be entering in that field? Is it something you know will keep a standard length? For example, will you be entering invoice numbers that are always eight characters long? Avoid creating text fields that will require space for a lot of characters or you could run out of room in your database tables.


When it comes to dates, how do you decide whether to use Date or DateTime for the field? Best practices would indicate you should use Date if you don’t particularly care about time, and DateTime if you must be able to report on both. A field that is date only will be easier to report on, filter, group, and enter data into, but of course if the time is necessary, you must use DateTime. Just be mindful that it is filled out appropriately.


Take care when using calculated fields or dependent fields. If you’re pulling data from a parent record down to a child record when using calculated fields, and you cascade those records down multiple levels (ex: Contact field based on parent Account field, and then Case field based on that contact field) and edit the account, you’ll have to cascade those changes down multiple levels. This may affect the ability to do an accurate calculation or even prohibit the calculation altogether. In the above example, if you have Workflows based on the Cases and you update the top parent Account (which updates the related Contacts, which updates the related Cases), each Case will kick off the Workflow.  If that Workflow updates the parent Contact or Case, you can get into quite the mess.


Additional Best Practices for Creating & Editing Fields

As you manage your field configurations, questions on enabling certain features may emerge. Here are our best practices for answering those questions:


1. To Require or Not to Require?

If you create too many required fields, there’s a higher likelihood your users will fill in the fields randomly just to be able to move on in the process. However, if you don’t create any required fields you may find your data has too many gaps and you can’t collect the information you need. So, what’s the solution? It’s a balancing act, but keep in mind that Sugar has other tools, like data scoring and exception reporting, that can help you keep track of certain data if you are worried about having too many requirements.


2. Enable Duplicate Merge?

Your Sugar instance will show a field property with the option to enable duplicate merge. Duplicate merge is when you merge duplicate records and get a side-by-side view of the data in that field. If you know you’ll have time to compare the two records completely, go ahead and merge, but if there is an overabundance of custom fields, you may find yourself with information overload.


3. Is This Personal Information?

Sugar added a new property called Personal Information in version 8.0. This was in response to the GDPR and other European data privacy laws. It allows you to mark which fields contain personally identifiable information. That information will feed in to the data privacy features, including being able to see all personal information on file in a record via a particular view in Sugar. The information also feeds into the data erasure process built into the data privacy module. You can capture this information at the request of a customer and erase it, copy and paste it, or do whatever else is asked of you.


4. Should This Field be on the List View?

This best practice tip is not a field property, but it has to do with fields so, here it is! Put thought into which fields are available as columns in your list view – prioritize the most crucial information your users will want to see in that field and don’t over clutter by showing too many columns. It will slow down your process.  


Managing Searchable Fields

How will the fields you’re creating be available for searching? Global Search, Search Filtering, and Reporting are all Administrator level configurations that are manageable for your searching needs. Here’s a breakdown of each:


Global Search: Global Search Admin settings allow you to select which modules should be indexed for Global Search (in the search Admin tool, not in Studio). With this high-level capability, you can turn off searching for modules you don’t want users to be able to use through Global Search. Within Studio, you can control which fields you want indexed for the search engine. This also controls how the results are ranked for your users via the Boost Value. You can adjust Boost Value to make sure you’re presenting the most important information to your users first.

If you type a search term that matches multiple fields on a record, the Boost Value from each field will add up to get the overall match for that result.


Search Filters: These filters are controlled through a layout in Studio. Within every module in Studio you have a search layout. You can drag and drop fields into your search layout so they can be searched. Keep the Search Filters in mind when you’re creating new fields. You may not want the particular field on a list view layout, but in most cases you will definitely want the new field to be on the search layout.


Reporting: The Admin can control which fields are available (or unavailable) for reporting. In most instances, if you’re disabling a field for reporting, it’s because your team is no longer using the field. You can hide fields from the Reports screen by unchecking the reportable property on the field under the field settings.


Modifying Dropdowns

Best practices for modifying dropdowns start with reviewing existing data, especially if you’re removing any values. Search the field for the values first, because once the values are removed, the related data in the database no longer exists according to Sugar. If you must replace the value, do the following:


1. Add new value to your dropdown

2. Go to Entity

3. Search field for your old value

4. Do mass update to the new value

5. Go back into your dropdown and remove the old value


For more Sugar Admin best practices, visit our website at www.techadv.com. Be sure to join us for our February user group on best practices for using quotes in conjunction with opportunities, products, and forecasting.

Want to stay in the loop on other TAI events, news, and more? Tell us what you want to receive, and we’ll send it.