Custom Object and Field Management

Source: This article refers to Custom Object and Field Management

In a Nutshell

The Coresystems Data Model utilizes data transfer objects to exchange and store data.

With Custom Data Objects and Custom Fields you can create custom objects and fields to fit scenarios that more closely align with your own business needs, and store data in the cloud for automation, validation, dashboards and reporting purposes.

These custom objects can then be used in Business Rules create and update object actions. Additionally, the custom fields that are defined and managed here can be used in the standard screens that are supported by the Screen Configuration tool.

ATTENTION: Custom object definitions created in Admin are by default NOT synced to an ERP.

Access

The Custom Objects Defintion screen is access at Admin > Company > Custom Object Definitions. Custom objects and custom fields are associated with a given company.


A Closer Look


Custom Data Object Defintion




A custom data object definition is where the fields/properties that define the custom object are set and managed.

Field Description
Name The name of the property of the custom object.
Mandatory On or Off. When On, the property will be mandatory.
Type When adding an additional field (property) to a custom data object, you will be able to select a data type.

Options include: boolean; date; date time; integer; float; string; time; referenced object. For more information, refer to the Custom Fields.
If the custom field has already been defined, this link will appear. By clicking on the link, the application will redirect you to the custom field definition view. If you edit the custom field definition here, it will udpdate all instances where the custom field is referenced.

Default Properties

The following properties are included by default in all custom objects. These properties serve as metadata to track the creation and modification of custom data object records.

Default Property Description
createDateTime The date/time on which the custom data object was created.
createPerson The person responsible for creaeting the data object record.
lastChanged The date/time on which the custom data object was last updated.
lastChangedBy The person responsible for performing the last update of the custom data object.

Custom Field Definition


A custom field is a field/property that can be associated with either a standard data object or a custom object. The following types of fields are supported:

Custom Field Type

The following properties/field types are supported:

Type Description
Boolean This type will evaluate the value to a boolean. For example there could be an internal field that was a boolean that if/when true, then neither the feedback nor the external would be displayed.
Date This data type can store a date without time and time zone information.
Date Time This data type can store a combination of date and a time zone information.
Integer This data type can be used to store numeric values without fractional values.
Float This data type can be used to store numeric values with fractional values within a specific range.
String This data type is used to store UTF-8 strings with a maximum length of 2'000'000 bytes.
Time This data type can be used to store time and time zone information.
Referenced Object When creating a custom property definition, you can select an object to which the custom property is related (example: PersonReservationType).

Custom Field Definition

A custom field definition will then appear as follows when viewed from the Custom Field Definitions screen:




Custom fields that have been defined can then be reutilized in another custom data object. When a custom field is updated, all instances where the custom field is referenced will also be updated.


Field Description
Name The name of the custom field.
Description The description of the custom field.
Mandatory Indicator. When filled, indicates that the field is mandatory.
Object Type For custom fields, this will be UdoValue.
Type The data type of the custom field (example: boolean).

Defining Custom Objects

ATTENTION: The name of a custom object definition must start with a CAPITAL letter and cannot contain empty spaces or special characters. In the example below, the custom object is named LocationHistory.

Custom Objects are defined in the Define Custom Objects view. It is here where you will define the properities associated with the custom object.

When you are defining a custom object, keep in mind that you are really creating your own data transfer object (DTO). Think of the custom object you are defining as adding your own table to our data model, like the Activity Feedback DTO table below:

Field Name Type Category Reference Description
activity Identifier Required Activity : 13, 14, 15, 16, 17 Activity for which the feedback is provided.
activityCodes List<Identifier> Required ActivityCode : 10, 11, 12 A set of activity codes of the target activity.
composedCode String Optional Composed code of the target activity.
equipment Identifier Optional Equipment : 14, 15, 16, 17, 18 Equipment linked to the performed activity.
externalText String Optional Text block which will be printed on the service report depending on the composed code of the generated Activity Feedback.
internal Boolean Required If true, then neither the feedback nor the external text will be printed on the report.
internalRemarks String Optional Remarks on the feedback for internal use.

With that in mind, let’s take a look at the following custom object example. This example could be used to store the location history of a technician for route optimization purposes (Note that the default fields have been removed for brevity. These are defined above.):



Viewed in tabular format, our LocationHistory custom object would then appear as follows:

Field Name Type Category Reference Description
code String Required The unique code associated with a given LocationHistory event.
dateTime dateTime Required The date/time on which the location data was recorded.
technician Reference Object Person: 15, 16, 17, 18, 19 The technician from whom the location data was recorded.
equipment Reference Object Equipment : 14, 15, 16, 17, 18 Equipment is generally used in service calls and activities as the end destination. In this case, it would be the final LocationHistory for a given activity.
latitude Float The latitudinal coordinates of the LocationHistory event.
longitude Float The longitudinal coordinates of the LocationHistory event.

This custom object could then be leveraged in a screen configuration, used in a report, or in a business rule action.


Using Custom Objects and Fields

Custom Objects in Business Rules

Note: The following video tutorial shows how a custom object can be used to send a customer a quote with history.

In the following example, when the conditions are met, a locationHistory record is created.



Trigger

In the exampe above, we define a variable for the Object UdoMeta with a condition or WHERE clause to get the correct object definition, e.g. WHERE Clause filter by name. In this case, the name of the object definition is "LocationHistory"

Create Object Action

In this example you would complete the following:

  1. Set the link from UdoValue.meta to UdoMeta.id via
    • Field Name: meta
    • Field Value: ${udoMeta.id}
  2. Define the values for the custom fields via “udf. " (in the above example we have **udoMeta.name = "locationHistory"**).

Custom Fields in Screen Configs

Custom fields can also be used in screens and web-elements supported by the Screen Configuration feature.

Whether the fields are visible, editable, and/or required must be configured in order to be functional. Custom fields do not come with default settings.




Custom Objects / Field in Queries

Custom objects and fields can also be referenced in queries, such as the following:

SELECT locationHistoryDefinition.name, locationHistoryDefinition.description
, locationHistory.createDateTime, locationHistory.createPerson
, locationHistory.udf.code, locationHistory.udf.dateTime, locationHistory.udf.technician, locationHistory.udf.equipment, locationHistory.udf.latitude, locationHistory.udf.longitude
FROM UdoValue locationHistory
JOIN UdoMeta locationHistoryDefinition ON locationHistoryDefinition.id = locationHistory.meta
WHERE locationHistoryDefinition.name = 'LocationHistory';
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

0 comments

Article is closed for comments.