Best practices on reusing query rule

It all comes down to maintainability and reusability. With new releases many old rules will have _23r2 etc versions in them and it wont use the latest offering. For each of these options

1. Multiple query rules for one record type - This given clear intent for the rule, optimisations are easier though in event of version updates there are a lot of rules to update to latest version and test. Increases chances of duplicate rules too. 1-2 such rules are enough. Otherwise not a good approach in my opinion.
2. One rule for each record type - Its good to implement and we pass the columns to query, filters, paging etc as rule input. The risk lies with filters - someone may accidently query 100k rows because this rule will allow it. Otherwise it is flexible and easily maintainable. 
3. One rule for all the records - this seems simple but I would be vary of this. Firstly by the rule name we wont know what it is querying. Though it is not a bad design but can become complicated and harder to debug in cases. I foresee a lot of regression risks as well whenever any change is made. It will be more complicated to maintain then the other two approaches. 

I personally, like to mix approach 1 and 2. Like one rule for a record type to render in grids etc. And another 1 or 2 rules to query that record type by primary key or status like active cases or case by Id for summary screens. Ultimately the goal is to reuse what can be reused simply without causing much overhead complications and dependencies. 

Reuse a single query rule only if it stays simple and returns just the fields and filters that use case needs. If different use cases force many if() conditions, dynamic fields, and optional filters, it gets complex and slow, so create separate, purpose-specific rules.

Record-level security is enforced by the record type on every query anyway, so splitting rules doesn't weaken security. And since security, relationships, and custom fields live centrally on the record type, that stays your single source of truth. So the number of query rules matters less than keeping each one simple and scoped.

We typically create Record specific expressions for reuse like rule!getRecordById() or rule!getRecordsByStatus. They return either a single item, or a datasubset. Other queries are typically specific to their local use case and not designed for being reused.

I prefer having one generic query rule for each record type.

I think the approach should depend on the project's size and complexity. Having multiple query rules for the same record type can create duplicate code and makes maintenance difficult. If something changes, we may need to update several rules.

At the same time, having one generic query rule for the entire project is also not a good idea because it becomes too complex and difficult to understand and debug.

So, I feel that one generic query rule per record type is the right balance. It keeps the code reusable, easy to maintain, and easy for developers to understand. If there is a special or complex query, then I would create a separate query rule only for that specific requirement.

For the data fabric, we start by creating 1 generic rule for each record type. These generic rules provide convenience but also enforce best practices. Once there is an example of one rule, duplicating the rule to use as a basis for other record types is really easy.

We like this approach because it keeps our code readable, greatly reduces the amount of rules to maintain, and most importantly, ensures developers are following best practices.

These rules have the following features:

• Return an empty dataset if
  • The record fields rule input is null, OR
  • All of the filterable column inputs (e.g. the primary key, types, other common things that get filtered by) are null AND the additional filters input is null.
• Every generic rule has rule inputs for
  • Paging Info (default: a!pagingInfo(1,100)
  • Additional filters (any type) to allow for re-use with some light customization
  • Fetch total count (default: false)
  • Record fields (list of Record Field)
  • Related Record data (any type)
  • The record’s primary key (List of Integer, usually)
  • Commonly filtered-on columns

For traditional Data Store queries, I enforce a best practice in every project I run that every new Data Store Entity be accompanied with a generic Expression Rule that does a general query and has certain default properties (usually copied from a template) where certain query conditions are passed in as rule inputs and (when non-null) have the QueryFilters automatically handled in the ER, but then for other ad-hoc or specialty QueryFilter use cases, the ER has a single “queryFilters” array that can be optionally passed, and also a “logicalExpressions” rule input that can be passed.  Also other standard things like “columns” and “pagingInfo” parameters, which are optional and override built-in defaults if passed.

For future updates to such an expression rule, I generally allow customized fields to be added as long as it can be verified that the new functionality doesn’t conflict with how the rule works in prior uses, i.e. when that input’s value is null.

I haven’t decided a best practice for Record Type queries yet, as I havne’t had a chance to use them quite as often in my current project - so far I tend to write them on-demand in the place they’re used, but that might not scale well I assume.  I’d need to consider whether the unified Expression Rule approach is still the best way forward.  Typing out all the recordType properties when writing these things out new is typically pretty frustrating, so a shortcut might help.

I have 2 rules:

1. Any logic inside a node of a process model, I extract into an expression rule for testability. This is the main reason I will make a rule for a query.
2. If I have a more complex query with more complex logic (other than just a filter on a specific field), I will make a rule out of it.

Otherwise, I’ll just use queryRecordByIdentifier or queryRecordType. I’ve been pondering about creating generic wrappers for queryRecordByIdentifier or queryRecordType to facilitate upgrades. But think this may not be needed anymore with Dev MCP. (i.e. please upgrade all the deprecated queryRecordType statements).

HI ​@sarathkumr268295,

There can be various ways to do it depending on the mindset, but in most cases, I have seen a single query rule for each record type, with dynamic field selection, pagingInfo, and filters.