Custom Fields Overview

Overview

Custom fields are a powerful tool to address specific scenarios. In contrast to standard fields that exist in every CommunitySuite site, custom fields allow each foundation to add their own fields to their site. This may be useful where specific information is being captured that does not have a designated location provided in the standard Foundant database.

Custom fields can be added to profiles, general ledger accounts, grants, scholarships, funds, donations, split interest agreements, internal loans, invoices, opportunities, and vouchers. 

You can use bulk import and update custom fields. Custom fields are available in some templates.

• Resource: Custom Fields in Templates
• Resource: Import and Bulk Update Custom Fields

Because custom fields are unique to the organization, there are functional limitations that are important to understand.

• Custom fields are best used for reporting and tracking. There are limitations to using them for workflows. 
• Custom fields are partially supported in filtering. Filter lists that show a specific pre-defined list of fields (profiles, donations, grants, pledges/promises, scholarships, general ledger) do not support custom fields. Filter lists where you see a [filter] link, such as in grants buckets, do support custom fields.
• Custom field data is only available using custom reports. Default reports will not include custom field data. As a result, custom fields work well for specific needs like basic coding of grants or coding an organization by a particular interest area where you want to be able to pull a custom report with that specific data.
  • Custom fields will not pull into any financial reports nor any of the filtering within the financial reports. 

Custom Field Types

There are five types of custom fields.

• Dropdown
• Multi-select
• Nested list
• Date
• Text

Think about your end goal when selecting a custom field type. If the field data will be valuable in reporting, think about how you would like it to display in reports. Setting up some sample data and reports in your Sandbox site can help you determine the best approach for your use case.

• Resource: Custom Field Types

Create a Custom Field

1. Navigate to the page for the record type the custom field will be placed.
2. Click Custom Fields in the left-side menu.
3. Click Create on the left-side menu.
4. Fill in the field details, then click Create.
   • Custom Field Name - This is the text you will see on the screen whenever someone views or edits a record. Choose a name that is easily understood by everyone in your organization. Avoid acronyms and abbreviations unless they are industry standard.
   • Custom Field Type - Select the field type from the drop-down menu. Options are dropdown, multi-select, nested list, date, and text.
   • Description - Description allows you to enter reference notes about how the field is used. This does not impact functionality or display to your users.
   • Required - Required means that this field must be given a value when a record is created or edited. This also applies when editing historic records.
   • Active - If checked, the value in a field can be set or edited. If this is not checked, the value cannot be changed unless the field is made active. An inactive field will appear on the screen if it has a value assigned.
     • All fields created within GLM or SLM are automatically marked as inactive once they are added to CommunitySuite. The field will need to be marked as active in order for it to appear on all CommunitySuite records. 
   • Display Order - Display Order allows you to change the order fields appear on the screen when there are more than one custom fields for a record type. The default display lists fields in A-Z order. 
   • Import Code - Import Code should be populated if this field will be used in a template, or if data will be imported into the field. More information on import codes is below.

   • Apply to Profile Types - This section only appears when creating or editing a profiles custom field. Uncheck any profile types where the custom field does not apply. For instance, in the example below Maiden Name would not apply to a organizations. Whether it applies to households is dependent on how you are managing your profiles.
     
     
     

Import Codes

Field Design Best Practices

One pitfall to custom fields is the risk of creating messy data over the long term. With too many or unused fields, it can become hard to find the data you need. Custom fields can become like a junk drawer, and we have a few pointers to avoid this.

• First, ask “Why do we need this custom field?” Will it be used to help make decisions, or is it just informational/reporting? Is there a way to accomplish this in the system already without adding the field? Do you already have another field that serves a similar purpose?
  • These questions also help clarify how you would design the field. If it is informational, it is OK to have it be a plain text field where anything can be entered. If it is going to be used for decisions or more advanced reporting, you may want to enforce particular values.
• Next, ask “Where should I attach a field?” The simplest way to think about where you want to put it is to ask “Where would I look for this if I wanted to change the value?”
• Also think about things like having more than one possible value. The more you add, the more you have to maintain. Once added, don’t be afraid to delete the field if it is no longer being used. 
• Last, it's important to control who can add/delete custom fields from your list. We recommend keeping tight control of this permission to avoid over-use.

Permissions for Custom Field Maintenance

Custom fields have their own separate permission that can be accessed in User Groups or from the Custom Field Objects screen.

Access the Custom Fields Object Screen

1. Navigate to the page for the record type the custom field will be placed.
   • Options are profiles, general ledger accounts, grants, scholarships, funds, donations, split interest agreements, internal loans, invoices, opportunities, and vouchers. 
2. Click Custom Fields in the left-side menu.
3. Click Custom Field Objects in the left-side menu.
4. Click Permission in the left-side menu.
   
   

By default, the admin group has full permissions and all others have view permissions. It is highly recommended that you leave it this way. Changing it to None for a group will remove their ability to display the list and access details of the custom field such as the import code value, which is needed if working with the field in other areas.

Advanced permission allows you to separate the create, delete, and edit permissions. 

Example Scenarios for Custom Fields

Now that you know how to define a custom field, it is time to put them to use. We’re going to use a few different examples for some custom field scenarios to learn some things we can do with them.

• Donation source 
• Grant coding and reporting
• Grant program workflow filtering

Example 1: Add a Donation Source to Donations (Basic Tracking)

This example will use a dropdown field to track donation source.

Let’s begin by creating the field. In your Sandbox site, go to the Donations module and click Custom Fields in the left-side menu. Click Create and create a custom field like what you see below.

In this example, dropdown has been selected to only allow one source for the donation. If you wanted to allow multiple values, you would create a multi-select field. Once you have created the field, create a donation. At the bottom of the donation, you will see this.

Click [edit] to assign a value. You can also click Edit in the left menu to edit the entire record. Either one will provide a dropdown list.

 

Note that you can only select one value and (other than blank) it has to be one of the values you entered as possibilities. This makes reporting easier and more consistent. In this example, it is highly probable that someone would want to see donations broken down by these source values. Since summarization is possible, we want to make sure our users are consistent with how they enter a value. Using a dropdown enforces that consistency. 

This is one of the single most important skills when you add a custom field. Always think about how it will be used once it has been entered. Is it just being listed, or do you want to summarize on this field?

Example 2: Grant Coding and Reporting (Using Custom Reporting and Bulk Setting Values)

In your Sandbox site, navigate to the Grants page and select Custom Fields from the left-side menu. Click Create and enter a field like this.

 

We now have a list of possible values. Users can apply one or more values to each grant.

If we’re adding grant coding, we may want to populate these codes on our historic grants. To do this, we can populate from a custom report or import custom field values into existing grant records.

• Resource: Import and Bulk Edit Custom Fields

Example 3: Grant Program Area Example (Custom Workflow)

The next example illustrates how to create a program area for grants used in grant processing.

As demonstrated in the previous examples, you can add and test this field in your Sandbox. Navigate to the Grants module and click Custom Fields in the left-side menu. Click Create and create a field like the one below.

Now, navigate into the grant Approval bucket. You’ll see several grants in this example.

Note we don’t see the custom field here. When you are going to utilize a field as part of the process, you will need to use filters. 

Let’s say you want to work with the Panther Needs grants. First, add the field to the filter. It’s easiest by using the search. Click Filter and type Program in the search area. This shows the Program Area as a result.

Click the Program Area link. Check the Panther Needs box and click Apply Report Filter.

The approval list now reflects records that meet the filter criteria.

 

Integrating Custom Fields with GLM/SLM

An integrated custom field is a custom field in both systems that is connected via the platform and will update from CommunitySuite to Grant Lifecycle Manager (GLM)/Scholarship Lifecycle Manager (SLM) and vice versa. It is vital that your CommunitySuite administrator and GLM/SLM administrator communicate and agree on which fields will be integrated and how the information will be used, as not all custom fields should be integrated. 

• Resource: Integrated Custom Fields