Object Type Attribute

Introduction

As mentioned in the previous topics “Objects” are the foundation for any Platform application. Likewise, the capability of “Objects” is now enhanced by introducing a new attribute - “Object Type”. The object type is a way to normalize a complex object as a “Default” object and extended “Object Types” within that object.

Object Types

“Object Types” can also be considered as sub-objects within objects which inherit all the entities (Fields, Relationships, Pages, Views, Templates, Reports, Charts, Gauges, Triggers, Workflow Button & Data Maps, etc.) of an object. When an object is enabled with an object type, the base object is categorized as a "Default” type which is a system-defined type for the base object. “Object Types” also extends the “Default” object by adding new entities (Fields, Relationships, Pages, Views, Templates, Reports, Triggers, Workflow & Data Maps) within the context of each object type.

“Object Type” enables the objects to:

  1. Be extended by adding one or many object types within the object, which can be further used as sub-objects from the “Default” type

  2. Be shared across applications while having application-specific fields, views, relationships, triggers, workflow, etc.

  3. Have the “Record Type” capability for an object. By creating individual create, edit, view, mass update, etc. pages for each Object Type within one parent/Default object definition.

  4. Retain the tenant level customizations in case of app updates of marketplace hosted applications.

  5. Install/Update specific Object Type while installing or updating the application.

Use-Case

Following is an example of an Agile Project management application that comprises the following objects and fields requirement.

  1. Project
  2. Sprint

  3. Issues

    a. Epic b. Story c. Bug d. Test Case
    e. Test Scenario f. PI Objective g. Sprint Goals h. Release Notes

  4. Release

  5. User
  6. Reports

In this use-case, the object “Issue” has extended sub-types like Epic, Story, Bug, etc. It also has some common fields/properties which are shared across all sub-types. And each sub-type has its specific fields, Workflows, Triggers and Reports.

Things to Remember

Salient Notes

  • It is highly recommended not to have more than 10 number of Object Types due to performance issues.

  • If an entity is cloned from "Type-1" to "Type-2", any attributes, fields, custom scripts, formulas, or properties specific to Type-1 are not carry forwarded into cloned instance (Type-2). The app developer should provide accurate information in the clone instance to make it effective.

  • Any specific field of type: CaptchaImage, IPAddress can be defined only once per object definition. If desired to define a field for more than one object type, it is recommended to define the same in the “Default type”, which then makes it available in all other object types.

Limitations

  1. Currently, the Object Type attribute does not support the following entities:

    1. Charts
    2. Gauges
    3. Button

    4. Roles & Permissions

      Note: Roles & Permissions for any specific Object type cannot be defined currently as it inherits all roles & permissions from the “Default” Object.

  2. The following system objects do not support the “Object Type” attribute:

    1. CUSTOMER, SUBSCRIBER, PACKET
    2. SETTINGS
    3. APPROVAL
    4. SURVEY
    5. Communication Log
    6. Department
    7. Function
    8. Group
    9. Location
    10. Published Application

  3. When the Object Type attribute is enabled for a specific object, Approval, Survey or Survey Taker attributes cannot be enabled.

  4. Data import is possible for each Object Type. In the UI import flow and the API import flow, the object type value is taken into account from the UI selection.

  5. An object can be extended upto one level only. The “Default” Type (base object) can be further extended by many other object types. The extended Object types cannot be further extended.

  6. System fields like “ID”, “Created By”, “Updated By” and “Record Name” field are associated only with the Default type.

  7. Object Type can inherit the entities from the Default type only and cannot share the entities across the other object types. Any information or entity which needs to be shared across the object type should be declared in the “Default” type (Base Object level).

  8. The Object type attribute cannot be disabled until all the user-defined “Object Types” are deleted by the app developer. This is to prevent the accidental disabling of the “Object Type” attributes while losing the metadata and data of the related object types.

  9. Certain functionalities of objects as mentioned below are not supported at the Object Type level:

    1. Attributes: As Object Type is a sub-object within objects, they have limited support for attributes (Contact, Location, Workflow, etc.). Attributes can only be enabled at the object level but not for a specific object type. This indicated that the attributes are common across all the object types.

    2. Special Fields: Some fields can be added only to the “Default” object Type, which is a base type for all object types. These fields are:

      1. Shared Image

      2. Version

      3. Auto Number

      4. Reference Record

    3. Dependent Picklist

  10. Any field can be added on any object type page for portals [View, Create, Edit].

  11. The app developer’s jurisdiction is limited to include sensible fields on portal pages only.

  12. Including fields other than default object type on portal pages are not recommended for create/edit/view as it could be constricted in the future iterations of the object type attribute.

  13. New Records from the portal pages are always created under “Default” Object type.

Enabling Object Types

The Object Type attribute is disabled by default and should be enabled in the Object Attributes section. To enable, check, and save the “Object Type” attribute from the Object Attributes section of the object Edit/Create page.

Once enabled, a new option – Object Types is available in the ribbon of the object definition page as shown below:

The app developer can create an object type within the object and can extend the objects for multiple applications. Simultaneously, there are some significant changes observed at the object level which are detailed below:

  • “Default” Type: A “Default” object type is a system-defined object type that is created as soon as the app developer enables the “Object Type” attributes. This “Default” object type is the base type of the object and represents the original object along with all entities within the base object which is tagged against the “Default” type and while every object type inherits the entities within the “Default” type.

  • All the existing entities of the objects are marked against the “Default” object type.

  • The new view “All <Object name> (All Type)” is added under the “Default” type.

  • Each entity is grouped by “Object Type”.

  • All the supported entities are created in a specific “Object Type” context, which indicates that when an app developer clicks on the ”New” button of any entity, selection of the “Object Type” for the corresponding entity to be created against is needed.

Supported Actions on Object Types

Object Type attribute supports the following actions for each type. As the “Default” is a system-defined type, it can be only edited. User-defined types support the following actions:

  • New Object Type: A new “Object Type” can be created within the object which inherits all the entities of the “Default” type. The new Object Types inherit all the attributes of the object.

  • Edit: An existing “Object Type” can be edited to change its Name, Integration name, Default Process or Description whereas the default object can be edited to change only it's Name, Default Process or Description.

    • Allow Record Creation: Use this option to allow record creation from the list view page of the application. This option is available only for the "Default Object Type". To access this option, make sure no default object type records exist or at least one non-default object type is available.

    • Default Process: The workflow process to be used by default when creating new records. Select "Default Process" from the dropdown to revert to the object level default workflow process.

  • Clone: The Clone action enables you to clone the object type with all entities defined specifically for that object type.

  • Delete: The Delete action performs a permanent cascade delete for all the entities as defined for the object type. This action permanently deletes:

    • All records associated with this Object type. Ensure all of the required records are exported before deleting this Object Type as this action causes an unrecoverable loss of data.

    • All fields, relationships, pages, views, templates, charts, reports, workflows, maps, and permissions associated with this Object Type.

    • All relationships between this object type and any other object types.

    To access to this option, make sure the option Is Deployed is unchecked for the Object Type to be deleted.

Filtering by Object Types

The Object View Page is equipped by Filter by Object Type dropdown. This dropdown lists all the available object types for the given object. By default, the dropdown is selected with All option.

On selecting any specific object type to be filtered from the Filter by Object Type dropdown, all the entities list the selected object type along with the default object type. The following image is an example showing the Views for the selected object type Developer along with the default object type Ex-Employee.

Similarly, component creations are bound up by default according to the selected object type, avoiding the need to select the object type.