Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Tabular Reporting recipients can be re-used in Qlik Cloud using a standard QVD approach with a twist.
This can be helpful if you would like to define a single 'master set' of all recipients and then selectively use some or all of them in different reporting applications.
Some examples:
While QVDs are often used to reload portions of the same data into multiple apps, QVDs also store 'tags' which turns out to be exactly how Qlik Apps reference recipients, filters, and groups.
Lets take a look:
With Qlik Cloud tabular reporting, recipients, groups, and assigned filters can be loaded from any supported data source.
TAGs are used to keep track of which field in the data model represents the recipient, their email address, and optionally, their assigned filter and group.
A minimal sample script could look like this:
The sample script loads a list of recipients, emails, filters and groups as a single table, and then it tags the fields accordingly with predefined tags.
Loading this script 'as is' is enough to create the recipient store in the Qlik app as follows:
as well as the group definitions:
If we decide to store the Recipients table to QVD, as long as the STORE command is issued after the 'tag field' commands as shown below...
it results in a reusable recipient QVD file as follow
that when loaded into a new reporting app...
...will recreate all the recipients, groups, and filters in the new app with NO need to re-tag the recipient, filter, or group tags.
Why is this important? Well first you don't need to retag recipients in multiple places, but second you can unlock the reusability of the recipient file by:
1. Loading a subset of recipients for different reporting apps
2. Assign different filters to the same recipients for different reporting apps
3. Assign different groups to the same recipients for different reporting apps
In this example, a subset of recipients (3 of 6) are loaded into a reporting application by using a JOIN. Use the Email recipient field for the JOIN as it is likely the unique identifier. Note that any LOAD syntax can be applied to load only select recipients (such as KEEP, WHERE etc..)
In addition, this ample also makes new filter assignments and creates and assigns different groups specific to this application.
I hope this helps as a building block to devising a reusable recipient list .
Hi @JonnyPoole
That is obviously great and I am sure you know what I will ask next 😄
How do we create filters automatically? Load them from list or app or via api so it can be easier to create them and maintain? I am sure there is a way and I just didnt have time to discover it yet. I hope you have some guidence for us on that.
thanks
Lech
Yes I would love a way to dynamically populate the filter list. Reassigning filters is only part of the story.
There are a few endpoints inside the /apps endpoint family that allow you to GET, POST, and DELETE report filters. They are a type of bookmark, stored in the app.
https://qlik.dev/apis/rest/apps/#%23%2Fentries%2Fv1%2Fapps%2F-appId%2Freport-filters-get
Furthermore, a community user has already posted a sample on how to operate these API endpoints in the load script (today actually :)) which might have to serve for now.
We are looking at the best option to try address through product enhancement. If you have any ideas please feel free to share. It would be great for us to validate. Unfortunately I can share no time line at the moment. But I agree this is needed 🙂
HI @JonnyPoole
Thanks for the links - I can work with this now.
I need to familiarize myself little bit more with the process and once I do I can come back to you on "product enhancements".
regards
Lech
@Lech_Miszkiewicz the app/<ID>/report-filters endpoint has now been allow listed for use with the 'RAW API Request' block in QAA making it a little easier to generate report filters dynamically in Qlik Cloud. It not unreasonable to use QAA to reload the app (which also updates recipients), add/update report filters using the RAW API Request Block, and also trigger a report task execution (also via the Raw API Request block) as the /sharing-tasks endpoint has also been allow-listed. This results in the full app/report chaining use case. I'll be showing an example next week at Qlik Connect in Orlando. I hope to see you and other Qlik Reporting enthusiasts there.
See you next week @JonnyPoole 😎 I am already signed up for your session.
This was good article. Hopefully someone fill fix the bug where one falty email address prevents recipient lists from showing. Reload script does not give any errors but If you do the actual import recipient fuction from start it tells you that there is an error in the email addresses...