You’re offline. This is a read only version of the page.
230
Greetings.
Are there best practices for determining whether a custom CRM report should include pre-filtering or not, and whether filtering should be done through pre-filtering or by hard-coding the filter conditions in the fetchxml of the report's datasets, or both?
If we have NO pre-filtering, and put all filter conditions in the queries for the datasets, then this avoids any confusion as to the results when run by any user. BUT, it means the user can't inspect what filter conditions are in fact being applied.
If we use pre-filtering and NO hard-coded filter conditions in the query for the datasets, then the user must understand how to use the Advanced Find feature, and how to interpret the report results in light of the filters applied. The advantage is that ALL filter conditions are inspectable by the user, and can be changed as needed at runtime.
If we use pre-filtering AND hard-coded filter conditions, then things get very confused: how do the pre-filters modify the underlying dataset queries?
I would appreciate any feedback on this, including proven SOP.
Thanks!
*This post is locked for comments
I have the same question (0)
Hi Danny,
Pre-filtering is really one of those things that there aren't great hard and fast rules for it. It is more a matter of how either how users are trained, or how you want to train them on using a specific report or report set. The only time that you must use pre-filtering is if you want a report to be able to run from a record form, like the Account Overview or from a list of records on a view.
Sounds like you already have a good handle on the pros and cons as far as using them for the Advanced Find like functionality, that decision is really more of a training preference than anything.
As far as how pre-filtering effects the underlying dataset, think of them as another filter criteria that is injected in. The exact method of how that is accomplished is covered out on the pre-filtering page but the best way to think of it is, they are just another addition to the "where" clause on your data set.
Best practice is to pick one method, one design methodology and just stick with it. Switching back and forth is going to be what causes more confusion for users than anything. My experience is that if you document and train it well, then the users will be ok but if they have to remember method A for this report and method B for this one and method C for the last...that's where you lose them.
Share
Report
All responses (
Answers (
