Custom fields allow each organization to add fields to their CommunitySuite site that are not part of the standard fields that exist in every site. They can be added to profiles, general ledger accounts, grants, scholarships, funds, donations, split interest agreements, internal loans, invoices, opportunities, vouchers, and notes. Bulk import can be used to update custom fields, and custom fields are available in some templates.
Who: Administrative staff who need to capture organization-specific information not available in standard CommunitySuite fields.
When to Use Custom Fields
Use custom fields in CommunitySuite when:
- Specific information needs to be tracked that does not have a designated location in the standard site database.
- Grants, donations, or other records need to be coded for reporting purposes.
- Organization-specific workflows require filtering or sorting records by custom criteria.
Custom Field Limitations
Custom fields are best used for reporting and tracking. There are limitations to using them for workflows. Because custom fields are unique to the organization, there are functional limitations that are important to understand.
Filtering Support is Partial
Custom fields are partially supported in filtering. Filter lists that show a specific pre-defined list of fields, such as profiles, donations, grants, pledges/promises, scholarships, and general ledger, do not support custom fields. Filter lists that display a Filter link, such as in grants buckets, support custom fields.
Default and Financial Reports Do Not Include Custom Field Data
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 a custom report with that specific data is needed. Custom fields will also not pull into any financial reports nor any of the filtering within the financial reports.
Create a Custom Field
To create a custom field in CommunitySuite:
- Navigate to the page for the record type where the custom field will be placed.
- Click Custom Fields in the left-side menu.
- Click Create in the left-side menu.
- Enter the applicable Create Custom Field information, and then click Create.
- Custom Field Name - This is the text seen 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, date, and text.
-
Description - It is recommended that reference notes about the field be used.
- This does not impact functionality or display to 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.
- If this is not checked, the value cannot be changed unless the field is made active.
-
Display Order - Display Order changes 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.
- Additional information on import codes is below.
-
Apply to Profile Types - This section only appears when creating or editing a profile custom field.
- Uncheck any profile types where the custom field does not apply.
- In the example below, Maiden Name would not apply to organizations. Whether it applies to households is dependent on how profiles are managed.
- In the example below, Maiden Name would not apply to organizations. Whether it applies to households is dependent on how profiles are managed.
- Uncheck any profile types where the custom field does not apply.
Import Codes
Import codes must have unique values. They can be left blank if a field is only going to be used on-screen and in reporting. They need to be populated to use the field in a template or bulk import data into the field. In order to make sure the value is unique across the system, it is recommended that a prefix with an underscore based on the record type at the beginning of the import code. Import codes would be structured as prefix_fieldname. Import codes should not contain spaces or special characters such as periods, commas, ampersands, etc.
Example Import Code Prefixes
- Donation - dn_
- Fund - fd_
- GL Account - gla_
- Grant - gt_
- Internal Loan - il_
- Invoice - inv_
- Opportunity - opp_
- Profile - pf_
- Scholarship - sch_
- Split Interest - si_
- Voucher - vch_
Field Design
One pitfall of 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 specific data. Custom fields can become like a junk drawer; a few recommendations to consider to avoid this are below.
Why do you need this field?
Ask whether the field will be used to help make decisions or is just informational. Consider whether there is a way to accomplish this in the system already without adding the field, or whether another field already serves a similar purpose. These questions also help clarify how the field might be designed. If it is informational, a plain text field where anything can be entered is acceptable. If it will be used for decisions or more advanced reporting, enforcing particular values may be needed.
Where should the field be attached?
The simplest way to think about placement is to ask, "Where would I look for this if I wanted to change the value?"
How many values will the field need?
Think about things like having more than one possible value. The more that is added, the more that has to be maintained. Once added, do not be afraid to delete the field if it is no longer being used.
Who should have permission to manage custom fields?
It is important to control who can add or delete custom fields from the list. It is recommended to keep tight control of this permission to avoid overuse.
Example Scenarios for Custom Fields
Example 1: Add a Donation Source Custom Field to Donations
To add a donation source custom field to donations for basic tracking in CommunitySuite:
- Navigate to the Donations page and click Custom Fields in the left-side menu.
- Click Create in the left-side menu.
- Enter the applicable Create Donation Custom Field information, and then click Create.
- For this example, enter the text as shown in the image below.
- Dropdown has been selected to allow only one source for the donation.
- Create a multi-select field if multiple values should be allowed.
- Create a multi-select field if multiple values should be allowed.
- Navigate to a donation.
- Click [edit] on the custom field name to select from the drop-down menu.
- Select the applicable value, and then click Save.
- Only one value can be selected which makes reporting easier and more consistent.
- Only one value can be selected which makes reporting easier and more consistent.
In this example, someone would probably want to see donations broken down by these source values. Since summarization is possible, it is important that 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 adding a custom field. Always think about how it will be used once it has been entered. Is it just being listed, or will it summarize?
Example 2: Create a Grant Coding Custom Field for Reporting
To create a grant coding custom field in CommunitySuite using custom reporting and bulk setting values:
- Navigate to the Grants page and click Custom Fields in the left-side menu.
- Click Create in the left-side menu.
- Enter the applicable Create Grant Custom Field information, and then click Create.
- For this example, enter the text as shown in the image below.
- For this example, enter the text as shown in the image below.
A list of possible values now exists, and users can apply one or more values to each grant.
If grant coding is being added, then populate these codes on your historic grants. Populate codes to existing grant records by using a custom report or importing custom field values to the records.
- Resource:
Example 3: Create a Program Area Custom Field for Grant Workflows
To create a program area custom field for grants in CommunitySuite using a custom workflow:
- Navigate to the Grants page and click Custom Fields in the left-side menu.
- Click Create in the left-side menu.
- Enter the applicable Create Grant Custom Field information, and then click Create.
- For this example, enter the text as shown in the image below.
- The next step is to apply this custom field to grant records. For this example, we will assume that has been done.
- For this example, enter the text as shown in the image below.
- Navigate to the Grant Approval bucket, and then click Filter.
- When custom fields are used as part of a process, filters are used to sort to the applicable field value.
- When custom fields are used as part of a process, filters are used to sort to the applicable field value.
- Enter the value being used to sort in the Search Filter By field, and then click the name.
- For this example, enter Program Area.
- For this example, enter Program Area.
- Check the Aviary Issues box, and then click Apply Report Filter.
The grant approval list now reflects records that meet the filter criteria.
Integrate Custom Fields with GLM/SLM
An integrated custom field is a custom field in both systems. It can 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.