Restricting modifications to a pre-defined filtering...

[Ssb_94]

Hello Folks,

We have a technical workflow, which is generic and templatized. Within that we have few targeting and action activities. There is a query activity, in which a condition is pre-defined within edit query at template itself.

Business User who is creating a workflow from this template can use the pre-defined condition AS-IS or can add any additional condition(s) on top of it, but should not be able to modify / update / delete the existing condition. 

We are looking at either restricting business user from modifications (or) if possible completely hide the condition for a business user

How can we achieve it? Any insights or suggestions.

Regards,

Sri Bhargav

[Jonathon_wodnicki]

Hi,

There are a couple options here, in order from simplest to most complex:

1. Apply a filtering typology rule to delivery template for deliveries made for that campaign. This can be further secured by hiding typology selection from business users. Downside is it moves the filtering all the way to delivery send which a lot of marketers don't like (harder to see true count, makes workflow approval worse).
2. Generate recipient lists with the criteria applied ahead of the workflow, as part of ETL. Can't really secure, have to delete old lists, can get confusing.
3. Alter the workflow template to add js in workflow Properties' Script tab: JS parses the workflow's xml on workflow start, looking for query activities that are missing required filters and halting workflow if present. Best to do this in a library and have a single call to it, e.g. validateXXXCampaignWorkflow(). Can hide Script tab from business users if desired. <- what I would do
4. Alter the xtk:workflow form to apply a <leave/> check on query activity to prevent tampering with workflow template's predefined filter. Requires arcane coding that can ruin system if not done right, breaks on upgrades.

Thanks,

-Jon

[LaurentLam]

Hi, according to me, the first question to ask yourself is why to have to restrict business users on queries...
If this is in order to do not be able to have access to data they should not see, a simple way to achieve that could be to use sysfilters on the schemas that are sensible. Filtering schemas | Adobe Campaign

For my part, I prefer "business users" to be more flexible on how to create queries more than creating for them predefined filters each time they have a new requirement: even if training them can be seen as a waste of time on short term, we gain time on long term due to the fact that they're able to build their targets alone and even sometimes can have new target ideas while discovering all the schemas and attributes related to their mappings.

[Ssb_94]

Thanks Laurent for the suggestion