
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-21-2014 10:56 AM
We're in the process of determining the best way to separate data in our SN instance. So far from what I currently understand of our business requirements I think Before Query Business Rules are going to be the best fit for our needs. I've found lots of pros for the use of this type of BR, but I'm wondering if there are any cons. For instance, a con with using ACLs is the impact on system performance due to the each record being queried every time the table is accessed. Is there anything I need to be aware of in regards to Before Query BRs?
Thanks,
- Sherry
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-23-2014 06:46 PM
Hi Sherry,
As far as performance goes, I don't think there are many downsides to query business rules. The biggest downsides would be that there is heavy scripting involved, so no role list or condition builders like you get with ACLs. Not only does that make it a bit tougher to build, but a bit tougher for someone else coming along after you to maintain. The other downside is that query business rules only work for record level read access whereas ACLs give you more granularity and different types of access. That being said, since you're looking specifically at data separation query business rules are a good way to go.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-21-2014 11:36 AM
I generally recommend using Before Query business rules for setting fields on the current record. After Query business rules are best suited or updating other records.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-23-2014 06:46 PM
Hi Sherry,
As far as performance goes, I don't think there are many downsides to query business rules. The biggest downsides would be that there is heavy scripting involved, so no role list or condition builders like you get with ACLs. Not only does that make it a bit tougher to build, but a bit tougher for someone else coming along after you to maintain. The other downside is that query business rules only work for record level read access whereas ACLs give you more granularity and different types of access. That being said, since you're looking specifically at data separation query business rules are a good way to go.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-10-2018 04:33 AM
Pro:
- In general, if you restrict user access to certain records via ACLs, you need to also have before query business rules to filter the records out from lists, so the users can properly find the records when using pagination etc.
- You also need to use before query business rules if you have some aggregate reports (pie charts, bar charts etc.) that should be filtered depending on the user who views them. ACLs don't affect these reports
Con:
- Query Business rules use a slightly different logic than ACLs. Rather than granting access based on certain conditions, Query Business rules restrict access by applying an additional condition to queries. That means that to construct the same conditions, you have to convert your logic into a different logical form (conjunctive normalized form to be precise).
- That also means that Query Business Rules don't allow the "new query" operator (^NQ), meaning that it's very hard to implement a query business rule that grants access to multiple sets of records with different conditions, if you cannot convert to CNF.
- For more complex Query Business Rules that use complex logic and/or database queries, there will be an additional performance cost.
Note that Query Business rules are not meant to replace ACLs, but to be used in addition. Also, keep in mind that Query Business rules can have an impact on queries that you use in your business rules (before and after, but not async).