1. Home
  2. Docs
  3. Isimio Installation and U...
  4. Data Model Configuration
  5. Manual Configuration: Fields

Manual Configuration: Fields

A Schedule Object record defines the properties of an object as a whole. In addition to it, we also need to define Schedule Fields, which control which fields are loaded for objects and what their purpose is. Each field defined under a schedule object record will be loaded into the scheduler, and can be used in a variety of ways.

Some field attributes are explained in About Objects and Fields.

When creating a new Schedule Field record, the Name must indicate a valid Field API Name of a field that exists in the schema for the parent object. For example, if your object is Contact, your field may be AccountId or FirstName.

Field Attributes

In addition to the name, fields can be tagged with several attributes that determine how they behave:

Visible fields appear on records inside the scheduler. Although there is no hard limit on the number of visible fields per object, for readability purposes these should be limited to the most important ones. We recommend no more than 6 fields.

When a relational field (lookup or master-detail) is marked as Visible, and the swimlanes are set to be the same as the field, the value will not be shown on the record. This is because the value is already shown in the row header.

Editable fields appear in the edit form when a user double-clicks a record. Note that certain field types may not be fully supported for editing, such as Geolocation.

Attribute fields will have the field name and value set as an HTML attribute of the node that represents the record. This can be used to develop CSS rules or Javascript functionality for advanced UI customization.

Show as Tag marks a field to be shown as a circle at the bottom-right corner of the record, next to the warning icons.

Show Label displays the field label before the value. This only works for fields that are marked as Visible.

Filterable fields appear as options to select as filters inside the scheduler. Supported field types are Picklist, Lookup, Master-Detail, Number, and Currency.

Photo URL is used for Row objects, and indicates that this field contains a URL path to an image. This image will be displayed next to the row name in the leftmost column.

Do Not Copy indicates that, when copying and pasting a record, the value of this field should not be copied over to the new record.

Required indicates that a field should always be required when creating or editing a record, regardless of its schema definition. If this field is unchecked, a field might still be seen as required if it is marked as such in the field definition.

Counted fields display a sum of this field’s value, per row, across all visible dates. The sum is displayed under the row name. Only numeric fields are supported.

[Beta] Dependent On allows the selection of another field on the same object. This field must be a date-time field. The date portion of this field will be used to set the date on the current field, and change the input type of this field to capture time-only, instead of date and time.

[Beta] Repeat Days is used to make a record repeat on certain days of the week indefinitely, regardless of the time range of the scheduler. This should be a Text, Picklist, or Multiselect-Picklist field with the value(s): Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday

Additional Attributes

Load Order determines the weight of the field when it is presented on a record or in a record edit form. The higher the number, the lower this field will appear. You may use fractions to easily place new fields in between two existing ones.

Default Value defines the default text that is presented in the field when creating a new record from inside Isimio. If not set, Isimio will try to use the default value from the field definition in your Salesforce schema – however, it does not support default values which use formula functions.

Do Not Copy indicates that the value of this field should not be copied when cloning a record using Copy/Paste or Repeat in the scheduler.

Primary Relation To only needs to be used if one object has multiple relational fields to the same parent object, and you want to actively designate a field to serve as the primary relationship to that object. If left undefined, one of the fields will be used as the primary relationship arbitrarily, which would affect how records are displayed when setting that object as the current Row object.