Is it somehow possible, either within the binder itself, or within the process, to say which intersections (i.e., location-product) to run on the report? I’ve got a report that would be a PITA to copy and then also manipulate every week - users can go fairly granular - location-product-customer - if they so choose - but for the summary report I send out weekly, I really only need the product level.
I thought I saw this once, somewhere, but I don’t recall where.
Hi Michael,
The report binder essentially runs all combinations of the pages.
Let’s say you have 2 dimensions selected in pages
Organization: 4 members
Version: 2 members
The report binder to this one report will create 8 pages.
In your instance, if you only want it at the product level, then I would point the other page dimensions to All members so that it aggregates.
What I’ve often seen clients do is maintain another copy of such reports (tagged to the report binder process) that only has the short list of page members that need to run in the report binder process, perhaps through a named set that they can use to control.
Hope this helps.
Cheers,
Navin
thanks; sort of what i figured but it was worth a shot.
@michael.senchuk, it’s a bit of a workaround, but a construct we’ve used for something like this might work for you. We create a read-only user with an email address that pertains to a distribution list. That read-only user has access to the dimension members you want in your report. We then send the report binder to that read-only user with that specific permission set. This creates a reduced-set of reports in the bundle, and still distributes it via email.
The upside is that we can use a single template for different slicing and dicing. Also, users who have visibility into multiple dimension members get multiple reports, rather than a single report with multiple tabs. (This could be a pro or a con, depending upon your corporate culture. But in our case, we have entire teams devoted to jobs, and so we want our report binders to be job-focused, not recipient-focused.)
The downside is that management of the actual recipients of the report has to happen in the email distribution list, not Prophix itself.