Extending Object with Object Types
The object type feature enables the app developers to define entities within the context of Object Type and the application which includes these “Object Type” to implement these entities. After enabling the “Object Type” attribute, the app developer can view an additional pop-up screen in the flow of entities created to select the “Object Type” for which the entity needs to be created.
The object types extensibilities are explained for the following components:
Fields
Object types can inherit all the fields (as listed in the following Use-Case) from the “Default” type where the app developer can add more fields to the context of the specific object type except the ones mentioned in the limitations.
Use-Case
For the object “Issue” which can have multiple sub-types with additional fields as shown in the following illustration:
The fields listed under the “Default” type are common across all other object types and each type is extended from the Default by adding its own fields and workflow.
Text Field
All the fields including the text field display the context of the “Object Type” for which it is being created. This information is also available on the field Edit & View pages.
Formula Field
In the Formula field, the template helper has all fields from the “Default” type and “Epic” object type.
Document/Email Template Field
The document/email template field can be created in the context of the Object Type. The “Default Template” field shown in the list of templates is defined for the corresponding object type.
Related Field
A related field can also be created in the context of Object type and the only corresponding relationship appears in the “Related Object” for defining the related field.
Integration Link Field
An integration link field can be created in the context of the corresponding object type and the template helper shows the fields related to the Object type along with the “Default” type.
Note:
- All other fields have a common behavior for the default type as described for the Text Field.
- Fields for “Default” types are supported as normal objects. But for other object types, some fields are not supported as mentioned in the Limitations.
Relationships
Relationships for object types are supported as a normal object where the app developer can define the relationship between:
-
“Object Type” and other “Objects”
-
“Object Type” and another object’s “Object Type”
-
“Object Type” and same “Object Type” within the same object (Hierarchical relationship)
Currently, relationships are not supported between
-
any extensible and external objects.
-
an “Object Type” to “other Object Type” within the same object.
Relationships can be created with the default object type with access to all object types and individual grid controls for every object type of that related object could be configured. For more information on grid control, see Adding a grid control to a page.
Pages
In Platform, pages are auto generated on the creation of an Object. Object type also supports dedicated pages for each object type. By default, pages are not auto generated by the system on the creation of any “Object Type”. All pages are inherited until the page for specific object type is created and assigned by the administrator. Pages for any object type can be created manually by the app developer using the “Clone” action over existing pages.
Pages can also be auto generated on the following actions:
-
In addition to the fields of specific “Object Type” and “Add to Pages and Views” if any field is selected to be added on any of the “Default” type pages.
-
In addition to the relationship of Object Type and adding the lookup field on the pages.
-
Customizing the Create/Edit/View pages using page designer.
Assign Pages
An app developer can add more than one page for a specific action of an object type like Create, Edit, Mass Update, etc. Each of these pages can be assigned to any role from the Assign Page Versions section as shown in the following screenshot.
Views
Views are also supported for the Object Types like Objects. On enabling the “Object Type” attribute a default view “All <Object Name> (All type>)” is created which will show all records of all type. Along with it on creation of any “Object Type”, an “All <Object name> (<Object Type>)” is also created. This view works within the context of the specific object type. This view created for the specific object type has all the fields of “Default” type and the fields added to that specific type and will not include fields from any other user-defined object type.
As the above use-case mentioned Issue object has an “Epic” object type. So the “All Issues (Epics)” view has access to all the fields of “Default” type and all the fields of the “Epic” type marked with type name in braces. So for the “Epic” object type, the app developer can create views around the following fields:
Note:
-
On enabling the “Object Type” for the object, a system-defined view (which cannot be deleted) is created which shows records from All Type with all “Default” type fields, as they are common across all types.
- Cloning an "All Type" view carries forwards the "All Types" property and which can be used by the app developer to enable different views.
Configuring Object Types on List View
New Object type records can be quickly and easily created from the application's list view. With this, specific object type record creations can be configured from the Page Editor. To add/remove any object types from the available list of object types, do the following:
-
Navigate to the application's object you want to edit and click Design This Page to open the Page Editor.
-
Open the object's list view properties.
-
The Selected Object Types section list out the object types which are available for list views and record creations.
-
Save the page.
Templates
All types of templates support the object type attribute and the app developer can create the templates for any specific object types. The context for this template is the “Object Type” which is selected while creating the template. The app developers can see all fields in the Template Helper related to Object Type & Default only. The templates defined for the “Default” type are available at all other Object types as all the object types extend the “Default” type.
When a relationship is created against the default object type, tokens for all types are listed under one object Related Object Name>(Default) and are grouped based on object type.
Email Template
Email template within object type will provide capability to define a email template for specific object type and it works only with Default & corresponding object type fields, can be used only for corresponding object type records. Entities created for corresponding object type can only have access to the template defined within the object type.
Document Template
Document template within specific object type are meant to work for records of corresponding object type.
Record Template
Record template as well can be defined for any object type for specific record of that type to use as template and it will work for corresponding object type only. This will be available in corresponding type of entity for further usage.
For example, while creating a template for Epic type, the app developer can view the following options in the template helper. All the fields of the “Default” type and “Epic” type can be accessed by the app developer where the Epic type fields are marked with object type name appended with the field name.
Reports
The object type attribute supports all types of reports. Reports can be defined in the context of the Object Type. Similar to other entities, reports have the accessibility of fields and union of “Default” and specific object type.
Reports defined for the “Default” type are available for other Object types as all object types extend the “Default” type. The following are the instances for different reports which can be created for the “Epic” type:
Tabular Report
The tabular report can be built for any specific object type and the context for the reports is the “object Type” for which the report is created. This report is not available in other Object Type. For example, a tabular report is created for Epic status by Fix Version, sorted by Workflow Status & Assigned to and can have further layers (using Epic-Release relationship) added if the Epic is spread across versions/releases.
Document Template Report
A document template report works similar to other reports where the app developer can select the “Object” to create a “Document Template Report” and then set the context for the report. Based on the object type in the context, the report provisions the fields to be used which is “Default” and the specific object type.
HTML Template Report
An HTML template report can be created for “Object type” and similar to other entities the context is as per the selection of object type. For example, the following HTML Template report is created for the “Epic” object type and the template helper shows the fields in the context of Epic & Default type.
Javascript Report
A javascript report can be created for the “Object Type” and the report needs to be in the context of the corresponding object type for which the report is created. For example, the following javascript report for the “Epic” type shows views of “Default” and “Epic” type for looping.
Record Specific Custom Report
A record specific custom report can be created for a specific “Object Type” where all the fields are listed from the “Default” and “Object type”. For example, the following report is built for the “Epic” object type and the token helper shows all the fields from the “Default” and “Epic” object type.
All Records Custom Report
All records custom reports can be created for the “Object Type” and the custom reports can work with any objects within that application. So the context for the report is based on the selected source object and related object and object type.
All section types do support the object types. For Sub-Report Section Type, the report drop-down populates the non-custom reports of the Default type and the type of the parent report. For example, the following All record custom report is created for the “Epic” object type and in the source object dropdown, only types associated with the application are listed if app context is available.
Triggers
Triggers can be created for any specific “Object Type” and are invoked in the context of the records belonging to the corresponding object type. Similar to other entities, triggers defined for the “Default” Type is inherited to the object type.
For example, if an app developer creates an “on create” timing Trigger for the “Epic” object type and if “Default” object type also has an “on create” timing trigger defined.
The following behavior can be observed:
-
Default Record create: On creating the “Default” type record, “Default Triggers” is invoked without invoking any other trigger.
-
Epic record create: On creating the “Epic” type record, both “Default Trigger” and “Epic Trigger” are invoked (as epic type inherits all the triggers of “Default”).
All different triggers show the fields and information with the context of the corresponding “object Type” and “Default” type.
Run Trigger Scope
Select the object type for the Run Triggers action scope. Any selection made against the non-default type, lists all the triggers tagged against the default object type and the selected object type (if any). Selected triggers will run for all the records tagged against selected object type. Even if the "Default" trigger is selected for "type-1" run triggers action - the trigger runs only on all "type-1" records.
Unique Records Combination Triggers Scope
Select the object type while creating this trigger.
For triggers created against the default object type - Unique combination of fields are evaluated against all the records. This is due to the default fields being a part of all the records of the object definition irrespective of type.
For triggers created against non-default object type - Unique combination of fields are evaluated against the records tagged with non-default object type (even if they are default or non-default fields).
Run Triggers on Related Records
A trigger can be created against any related object type by selecting the appropriate type from the drop-down menu during the creation process. Selected related triggers from the Group of Triggers run based on the above Relationship Object Type.
Workflow
Workflow can be defined for any object type where each process belongs to a specific object type. The process defined for the “Default” type is available for every other object. The same implies to “Workflow Action” and “Workflow Status”.
There can be more than one process for the specific Object Type (as the Default type process is common across all types). A Process Selector is needed on the record Create/Edit page. By default, all “Object Type” defaults are selected to the “Default” process.
It is mandatory for an “Object Type” to create or select an existing Workflow Process for its Workflow Status & Workflow Action.
Batch jobs
Batch jobs (Scheduled FTP Import and Data Maintenance) which used to work on a single object scope can now be selected against a single object type scope in order to get support on extensible objects. This determines the scope of the set of records against which the batch job action is performed. This provides flexibility on defining operation to work on records belonging to the same object type only. Likewise, in order to perform the similar action on all other records of extensible object, batch job should be defined per object type.
Data Maps
Object Type can have “Data Maps“ defined for every object type. Similar to other entities, data maps also work in the context of the Object type and have access to all the fields of “Default” and corresponding type.
For example, the following data map is created to convert the record of “Epic” to “Bug” type.
-
Data import is allowed per “Object Type” where the Object type column is required for the import. It is not required for the object type column in spreadsheet or csv file to be mentioned. It is pre-selected via UI controls, Batch jobs or Data maps at the metadata layer.
Card View
Alike the list views, a Card view can also be created against the Object Type attribute. While creating new a card view, the choice of the object type can be read seamlessly from current list view. List of the available fields for the card design is based on the card’s object type.
Import Records
Like the other entities, Platform also enables the Import Record flow to support the Object type attribute. The app developer can import record to a specific object type from the import menu.
From the existing use-case scenario, on selection of a specific object type (Epic), the subsequent pages display Issue (Epic) accordingly. In the field mapping screen, only the object type specific and all the default type fields are displayed. That includes the object type displaying the set value (Epic).
Application Import/Export
Application Import or Export via application’s xml file carries all object types attached to the application. It is only possible to export a single object type of any extensible object of the application. The “Default” object type is always exported irrespective of its choice in the application attachment. Information about object types that are part of application can be viewed at the application’s tree diagram.
During the application xml export/import, selection of any entity is possible at the object type level even for a partial locked application. Herewith, selecting "TYPE-1" also ensures all other fields, triggers etc which are part of TYPE-1 are also selected.
