Custom Fields

Nearly every business has unique characteristics and unique pieces of data that need to be stored and tracked. SCP provides several tools to make it easy to do this, including leveraging "extra" fields on each entity, custom "settings" records for many entities, and facilities to collect custom information from users. Here is a summary of the topics in this document:

Custom (Extra) Fields

Many of the entities in the system, such as products, orders, suppliers, etc., have "extra" fields that you can use for whatever purpose you need in your business or workflow.

Out-of-box, the "extra" fields can be found on many forms, and they are simply named "Extra 1," "Extra 2," etc.

Extra Fields and Ecommerce Orders

Product Catalog Extra Fields Saved With Orders

The extra fields for Products, Attributes, and Options, have an added benefit: as a customer places an order, these extra fields will automatically be copied into the new Order Items and Order Item Attributes in the customer's cart. These values are then saved in the placed order and can be included in reports or exports.

Consider for example if your options have special part numbers that must be saved with the order in order for your team to efficiently fulfill the order. By uploading the part numbers into each option's extra1 field, for example, that piece of information will automatically get passed into the order and available for viewing or processing.

Adding Extra Fields for Orders To the Checkout Process

Administrators can also collect information from customers that the system will store in the Order's extra1, extra2, etc. fields. Prompts for the extra fields can be added to the first screen of the checkout - where the delivery address information is collected from the user. To enable this, go to the Settings -> Address Settings screen, and check off which extra fields you wish to collect from the user under the Prompted Delivery Address Fields setting:

In addition, you can check off the same field under the Required Delivery Address Fields setting, to indicate the user has to submit a value.

When you have selected one or more extra field to be prompted for on the addresses screen, customer will see the field appear and be prompted to enter something. You will almost certainly want to change the label for the field to something other than "Extra 1". To do this, add an Application Message under the Site Content -> Application Messages screen. For the Message Key, use "orderForm.deliveryExtra1", and for the Content, enter the label you wish to use for the field. In this example we are labelling the field "Emergency Contact Name":

The result of these changes on the checkout screen looks like this - the new extra field is showing up and being prompted for:

When the customer enters and submits a value for that field, it will be saved to the Order's extra1 field, where administrators can see it, export it, and so on.

Changing the Labels for Extra Fields

To help identify the data, you can easily change the labels that are used throughout the administrator application for the extra fields.

As an example, let's say your business's suppliers are medical practices, each of which might have one or two doctors in it. When you create a new Supplier record, you can collect and store each doctor's name in the "extra" fields. To help keep track of them, you can then relabel "Extra 1" as "Doctor 1" and "Extra 2" as "Doctor 2."

To do this, go to the Application Messages screen. To change the label for the supplier's Extra 1 field, create a new Application Message with a "key" of "AdminField.Supplier.extra1.displayName." For the "content" field, enter "Doctor 1" as the new name of the label.

You can make similar changes for other fields and entities. As another example, if you sell books, you might consider changing the "Name" field to "Title" for products. To do so, create a new Application Message with a "key" of "AdminField.Product.name.displayName" and "content" of "Title."

The new labels will show up pretty much everywhere in the administrator interface, making it easy to manage the custom data.

Changing Labels for Entities

Your business might use different terminology than SCP does for the same or similar concepts. To avoid confusion, it's possible to change the labels used throughout the administrator for each entity (in addtion to the fields under each entity as described above).

For example, SCP has an entity we call Supplier. This is intended to identify the company that acts as the source of a product. In your business you might like to reuse the supplier concent to track medical practices, and so you might like to label them with the term Medical Practice. To avoid confusion, you can relabel Supplier as Medical Practice throughout the administrator application. To do this, simply create Application Messages with the following message keys:

Note, the term "supplier" must still need to be used in more technical places, such as the Filter String fields for Reports. In general, most users will not need to worry about these cases.

Settings Entities for Custom Information

The "extra" fields described above are available for use on almost every entity in the system. Each entity provides five such extra fields that you can use however you wish.

Certain entities, such as products, orders, and so on, might require more than five custom fields. For these entities, SCP provides a child "setting" entity where any number of records containing custom information can be stored and used.

Settings as Custom Fields On the Parent Grid Screen

It's easy to start using settings entities in the Administrator Grid. You can add a setting as a column on the parent's grid screen by simply entering the "code" for the child setting into the bottom of the Displayed Columns popup. Click the column icon and go to the bottom of the popup, and simply type in the "code" for the new field or fields you wish to track.

The system will then create additional columns for the setting codes, and allow you to use the pencil icon to add and edit their values. Even if you have not created the settings records, entering a value in this way from the parent's grid screen will create the record for you, and if it already exists, edit it:

This represents a great way to extend the system to store and track information essential for your business.

Settings Entities' Own Grid Screens

Each Setting entity such as Product Settings, Category Settings, Order Settings, or the above Unit Service Log Settings, has their own grid screen as well. So in addition to maintaining them on their parent's grid screen, you can maintain them collectively on their own grid screen:

This allows you to leverage all the Administrator Grid features such as reports, filtering, sorting, and so on. For example, you can main them in bulk by downloading an export, making changes, and then importing them.

For more information on using the grid screens, visit the documentation on the Administrator Grid Screen features.