Types best practices

When using the includeAncestors=true query parameter in bulk read requests, consider adding an ancestorFilter to the request to filter out any types you do not want returned. This improves type query response clarity and improves response performance since you're only receiving the types you need.

Utilize type inheritance to efficiently share properties and relationships across related type objects rather than duplicating properties across similar types.

• This practice will also allow more type query options for filtering your types (for example, querying types matching a specific className or BaseTypeId).

• Be conscious of the inheritance depth limit of 31 types (32 total types in the chain) when creating a hierarchy.

Prefer smaller bulk type creation payloads when reasonable.

• Type Management's bulk create endpoint can create many types at once, but due to validation logic safety nets that expand as the types backend is saturated with new types, the response time for bulk create requests will increase.

• This is a flexible recommendation. It is reasonable to send larger payload sizes when your data store has less stored types and dynamically switch to smaller sizes as you deem it appropriate.

Use reasonable diligence in updating the lifecycle state of types to match their intended availability. If there is a reason to mark a type as deprecated, do so to prevent new types from being created that reference an undesirable state. This reduces the work that may be required later if you delay updating the type lifestyle state since related types would now have to be deprecated first.

Analyze your types for validation rule violations upfront to reduce back-and-forth validation errors and follow-up fixes with your data store.

Utilize RemoteReferenceNames to add additional context to existing relationships.

• RemoteReferenceNames create bi-directional context between two types that are related and allow for more options when querying your types and better reflect the real relationships between two type objects.

  An example: Type Person may have an Employer relationship with a type Business, allowing you to ask (query) the Person type "Who do you work for?". However, it is just as reasonable to ask the Business "Who are your employees?" which is where a RemoteReferenceName of Employee may better reflect the true relationship between the types and empower your data store with more query options.

• Consider RemoteReferenceName uniqueness when creating relationships.