Configuration Best Practices
Learn about platform-wide configuration limits and recommendations that help you ensure stability, scalability, and performance in your Reltio tenant.
The Reltio platform provides the following configuration best practices across a range of topics and object types. Reltio encourages our customers to work closely with their Customer Success Manager (CSM) and/or Reltio Professional Services to gain clarity on these topics and optimize the configuration of their Reltio platform.
| Best practices | Recommended value (if applicable) |
|---|---|
| Entity Configuration | |
| Maximum number of OV rulesets for an entity type | 10 |
| Maximum number of match rules for an entity type | 10 |
| Maximum number of Reference attributes in an entity | 20 |
| Maximum number of Reference attributes from other entities to a single entity record (not related to nested attributes) | 100 |
| Maximum number of populated attributes in an entity | 200 |
| Maximum number of defined attributes in an entity type | 500 |
| Relationship Configuration | |
| Maximum number of attributes defined in a relationship type | 50 |
| Maximum number of relationship types defined between any two entity types | 50 |
| Relationship attributes must not contain reference attributes. | N/A |
| Crosswalk Configuration | |
| Maximum number of crosswalks in an entity or relationship | 200 |
| If a surrogate has been defined, it must be the same for all sources. | N/A |
| Match Rules Configuration | |
| Use negative match rules sparingly as they are resource intensive. | N/A |
| When creating a match rule on an entity type where a surrogate crosswalk is defined, ensure that the match rules account for all attributes in the surrogate crosswalk to avoid matching issues. | N/A |
| Entity or Relationship Configuration | |
| Maximum percent of an object’s attributes that must be nested | 25% |
| Attributes Configuration | |
| Maximum number of values present in an attribute | 4 |
| Nested Attributes Configuration | |
| Maximum number of sub-attributes in a nest | 50 |
| Nested attributes must not contain reference attributes. While the configuration technically supports this, it is not a supported use of the information model. | N/A |
| Location Configuration | |
When using a relationship to link a party to a location entity type, for example use of the HasAddress relationship type, ensure that all attributes like the ADDR TYPE attribute are held in the relationship type and not in the location entity. Otherwise, each time a new address is added, the system will disconnect the old one and connect only the latest, instead of maintaining multiple addresses by type. | N/A |
The cleanse configuration must contain the declaration, "ovOnly": "true", which ensures that only the OV of the address values will be sent for cleansing. | N/A |
| The configuration for address cleansing must have an AVC Code for Status Mapping. | N/A |
| At least one Address match rule must be defined. | N/A |
All address match rules must include a condition where the verification status ="Verified". | N/A |
| A surrogate key must be defined. | N/A |
| The list of attributes defined in a surrogate crosswalk must be the same that are configured in the match rule. | N/A |
| All the attributes that are used in the match rule must be defined in the surrogate crosswalk, even if the source does not provide the information. Even if the match rule is lenient, with few attributes, the same set of attributes must be used in the surrogate crosswalk. | N/A |
Define the survivorship strategy only for the lowest-granularity attribute, such as addressline1. All other address attributes must reference the same source as the lowest-granularity attribute, that is, the crosswalk that wins for addressline1. | N/A |
| Reltio cleanser crosswalk must have the highest source priority. | N/A |
| The cleanse button must be disabled in all UI configurations. | N/A |
| RDM Configuration | |
Maximum number of lookups created in one POST to an RDM tenant | 100 |
| Maximum number of lookup values for all types | 20,000 |
Delta Detection: Implementations MUST code delta detection and only POST updates and inserts. | N/A |
| If any attributes in the configuration use RDM, then all related attributes must also use RDM. Otherwise, attributes that don't use RDM won't support drop-down lists in the UI. | N/A |
| Every RDM Value set must include a source mapping for source "Reltio". | N/A |
The "rdmConfig": {...} setting in the L3 must be properly configured in order to link the MDM tenant to the RDM tenant. | N/A |
| LCA Configuration | |
| Use LCAs only for short-running operations, as they can impact performance. Carefully evaluate whether they're appropriate for your use case. | N/A |
| Ensure that the LCA is not manipulating data or calculating derived data based on a specific source. Such logic must be designed and implemented at the source integration layer. | N/A |
| Disable LCAs for high-volume loads, including both initial and incremental loads, whenever possible. | N/A |
| LCAs must not invoke Reltio APIs, as this can degrade performance and may introduce circular references. You must obtain Reltio Engineering approval for any exceptions. | N/A |
| Ensure that the LCA code does not contain memory leaks, exploits, or attempts to work with file system/network and any other slow devices. | N/A |
| Ensure that the LCA code does not contain Reltio classes defined in the LCA framework. | N/A |
| Ensure that the LCA code does not contain any hard coded credentials. | N/A |
| Ensure that the LCA code does not contain any output to a system. All outputs must be written using the logging service. | N/A |
Submit all LCA code to Reltio Engineering at least three weeks before approval. This allows time for thorough testing using the test harness available in the Reltio repository. To submit, file a support ticket with a link to a Bitbucket or Git repository containing the code. The ticket must clearly explain the LCA's goal and strategy. | N/A |
| Submit test-run logs that ensure that the LCA code is executed with the minimum throughput of 1000tps. | N/A |
| Submit test-run logs that ensure the latency due to the LCA call is no more than 10ms. | N/A |
| Submit test-run logs that ensure the LCA code can be run in the multi-threaded environment. | N/A |
| Ensure that the LCA code is well tested using the testing framework available on the Reltio maven repository. | N/A |
| Ensure that the JAR file(s) is compiled and signed with the Life Cycle Handler implementation. | N/A |
| Ensure that necessary filter condition is configured for every LCA (if applicable) in the L3, which will prevent unnecessary calls to the LCA module. | N/A |
| We recommend that the attribute name must never be repeated across the L3 configuration. | N/A |
| Streaming Configuration | |
| Ensure the streaming is disabled in the tenant if the applications it supports do not need streaming. | N/A |
It is recommended to configure only Entity and Reltio URI in the JMSEventsFilteringFields (physical configuration) for better performance of the tenant. | N/A |
| Disable the Streaming API before a task affecting large volume of data in the tenant such as Reindex the tenant. | N/A |
| UI Related Configuration | |
| Maximum Dashboard facets | 20 |
| Maximum Pivot facets | 20 |
| The number of tags displayed on the dashboard cannot exceed the maximum value. | 20 |
| Maximum number of entities rendered in relationship facet | 500 |
| Maximum facets on a page | No Max |
| Maximum Pivot attributes | No Max |
| Each entity has its own perspective defined (that is, no default perspective). | N/A |
| Each facet has proper labels defined. | N/A |
| All UI extensions have a unique ID (No ID used twice). | N/A |
| Data Loading Configuration | |
| Design data loads so that you do not update the same entity in a parallel thread in a single load (try to load each entity only once). | N/A |
| Load data in appropriately sized batches and threads. | N/A |