Custom Objects v1 only
Custom objects can be used for tracking custom record types in Neon CRM. Object records and even objects themselves can be created, updated, and deleted through the Neon CRM API.
Overview
By now, you are probably familiar with how to track transactions and activities associated with accounts in Neon CRM. For most organizations, Neon CRM is the central hub for data and being able to track this relational information is crucial for being able to understand the organization's fundraising and constituent management efforts. However, in some cases, you may need to track custom data types beyond the standard account, transaction, and activity objects that exist in Neon CRM.
Custom objects allow organizations to track types of data that do not fit neatly into the category of "transactions" or "activities". These objects often have specific properties associated with them and include custom validation rules to ensure data is entered properly by users.
Concepts & Terminology
There are a variety of components that make a custom object. You may have experience working with custom objects and these components in other systems. This section will summarize the concepts and terminology that Neon CRM uses for custom objects.
Object
A custom object or just object refers to the new record type in the system. You can think of the object as a new table in a SQL database or as a new class/object in an object-oriented programming language or more simply, as a new tab in a spreadsheet. An object is the "thing" to be tracked, such as a record of an application for a scholarship program or the adoption of an animal from a shelter.
Object Records
While an object refers to the new category of data that you will be tracking, object records are the "rows" of data in the object. These records can be isolated or linked to other records in Neon CRM through relationships.
In the Neon CRM API documentation, you will find methods for both objects and object records. Pay attention to the distinction between these two concepts. Even our own Neon CRM team will sometimes conflate these two terms in conversation.
Fields
Objects have properties. In Neon CRM, these are called fields. Fields can be text fields, dropdown menus, checkbox lists, radio buttons, toggle switches, and more. Some fields can have extra functionality, such as date-time fields, which allow users to pick a date and time from a date picker; or formula fields, which can calculate their values based on other fields.
Validation Rules
Fields can have validation rules to limit the scope and format of data entered into fields. Validation rules can allow you to filter certain forbidden words from a text field, require number fields to have a value in a certain range, or just require that a field cannot be blank.
Relationships
Most custom objects you build will have at least one relationship to another object. Relationships track the connection between different types of data. Custom objects can be related to standard objects, such as accounts or transactions, or to other custom objects.
A relationship is added to a custom object by adding a relationship field to the object. Only a single record from the related object can be selected in the relationship field. This field creates a "parent-child" structure where the related object is the parent and the custom object is the child. Because only one related object record can be selected in the relationship field while many custom object records can be linked to the same related object record, this relationship structure is also referred to as "one-to-many".
Layouts
When creating custom objects in Neon CRM, you also get to choose how users will view these objects in the Neon CRM UI using layouts. Layouts define what fields from a custom object are exposed to the user on object record entry forms, record pages, and list pages.
The fields that appear when entering, editing, or viewing a single object record are defined with a form/page layout. The fields that appear in columns when looking at a list of object records are defined in a list layout. There are further nuances to this topic, such as how to display fields for different types of accounts or on public-facing versus admin-facing pages, which you can learn more about in the API documentation for this feature.
API Reference
API methods related to custom objects.
API v1
Custom Objects
Object Fields
Object Validators
Object Records
List Layouts
Form Layouts
API v2
(None)