Best Practice for Technical Rule

[Soumyadeep_Das]

Hello Everyone,

  We are trying to understand the best practice from operational maintenance and performance perspective for technical rule creation. We have a requirement of creating 100+ unique technical rules for a current active user base of around 14k. There can be scenarios wherein ~100+ users can be onboarded in a single file import. We have a lot of conditions to check in each of the rules with respect to various user attributes to assign an enterprise role. We wanted to understand from the experts here on which option to follow so that we can make it less complex, more sustainable with improved performance. Please note that we have to run the Schema User Import job thrice/day as of now.

Option 1 : Put all the checks with values in the technical rules

Option 2 : Put all the values for checks in datasets and refer multiple datasets in each technical rule

[yogesh2]

You can refer to this link:
https://forums.saviynt.com/t5/lifecycle-policies-rules/tkb-p/lifecyclepolicies

[Soumyadeep_Das]

Thank you for this link but this does not talk about using Datasets in technical rules and its implications, if any.

[Manu269]

@Soumyadeep_Das  as a past experience, I have gone through option 1. Create a optimized Technical Rule with required values. Make sure to carefully use brackets between condition and also the operators.

Of course this would als require regressive testing, hence prepare the all possible corner cases.

[rushikeshvartak]

• Use dataset option as it will be cleaner approch and well maintained 

• When dealing with a large number of users and complex conditions, the choice between putting all checks directly in technical rules or using datasets to manage these checks can significantly impact performance, maintainability, and scalability. Let's evaluate both options:

  Option 1: Put All Checks with Values in the Technical Rules

  Pros:

  1. Direct Implementation: All logic is contained within the technical rules, making them straightforward to understand for someone reviewing the rules.
  2. Immediate Execution: Since the conditions are directly evaluated, there might be less overhead compared to fetching data from datasets.

  Cons:

  1. Complexity: As the number of rules and conditions grows, the technical rules can become very complex and hard to manage.
  2. Maintenance: Any change in the logic or values requires direct modification of the rules, which can be error-prone and time-consuming.
  3. Performance: Evaluating numerous complex conditions for a large user base can degrade performance, especially during peak times or bulk imports.

  Option 2: Put All Values for Checks in Datasets and Refer Multiple Datasets in Each Technical Rule

  Pros:

  1. Modularity: Separating values and checks into datasets promotes modularity, making the rules easier to manage and understand.
  2. Maintainability: Updates to the values or logic can be made in the datasets without modifying the technical rules, reducing the risk of errors and simplifying maintenance.
  3. Scalability: This approach can be more scalable as the logic can be reused across multiple rules and scenarios, and datasets can be optimized independently.
  4. Performance: While there might be an initial overhead in fetching data from datasets, the overall system performance can be improved with optimized data retrieval and caching strategies.

  Cons:

  1. Initial Complexity: Setting up and maintaining multiple datasets can introduce initial complexity in terms of design and implementation.
  2. Dependency Management: Ensuring that the datasets are always up-to-date and correctly referenced in the technical rules requires careful dependency management.

  Recommendation

  Based on the provided requirements and considering the need for sustainability, maintainability, and performance, Option 2 (putting values for checks in datasets and referring multiple datasets in each technical rule) is generally the better approach. This method offers better modularity, ease of maintenance, and scalability, which are crucial for managing a large number of users and complex conditions.