Help shape the future of AI assistance by participating in this quick card sorting activity. Your input will help create a more effective system that better serves your needs and those of your colleagues.
Every event, condition and exception wich is saved in a rule is saved with a name. It would be a time saver, if it is possible to reuse saved events, conditions and exceptions in other new/existing rules.
Agreed, I actually thought I was overlooking something since Launch lets you name these individually which made me think they were going into an inventory somewhere like data elements.
We've talked about doing this for a long time. There are some other things we're working on now that we feel are higher priority, but we'll get to this at some point.
I'd love to hear some thoughts on how you'd use it. Some more specific use cases and how you'd interact with it. Some questions to think about: 1) When you find an existing component from Rule #1 and add it to to Rule #2 would you want it to be the exact same component? Or should it just be a copy? Meaning, in the future, if I edit Rule #1 and change the component, would you expect it to also be changed on Rule #2? 2) How would you want to interact with it (I'm making stuff up here)? Make new Rule #2, choose to add an event, then select from existing events? Or perhaps go to Rule #1, select the event, then say make new rule from this event?
In my perfect world, multiple conditions could be arranged into functional modules that could be centrally managed. A change to the "condition pack" would be reflected wherever it is used.
In my perfect world, these "condition packs" could be defined at a company level and used across properties owned by that company. Perhaps these "condition packs" are contained within a generated extension that is then installed on properties where they are to be used. Certainly, a change in a pack would require a library build and promotion through environments in order to have effect in prod.
In my perfect world, there also be "action packs" that allow multiple actions to be sequenced and reused.
1) I think both options are valid use cases, so in this case I'd suggest an option to reference a component or to just copy it.
But maybe not reference a component from Rule #1 but store them in a separate place. Similar as it is done in the Analysis Workspace where you have your Component Builder but also lets you create components ad-hoc. I love this feature and I think this is a similar use case and some logiccould be reused.
2) Similar as you select Data Elements from the pool, let us choose from the corresponding pool (events, conditions, exceptions, actions)
And I also agree with stewarts16448458 with the "action packs", but this isn't as "urgent" as some basic component reusability.
We've been thinking and talking internally. These concepts on inheritance get really finicky when you get into the details. Some of the things we're trying to figure out and would love to hear from the community are these:
How would you want to add Condition Packs to a Rule? When you click the Add Condition button it asks if you want to add a single or add from an existing pack?
Can you make modifications to the Condition Pack itself at the company level? And if so, how should that propagate down to the rules where it is being used? Do they get pushed automatically onto the individual rules, or do you have to go to the rules that use the pack and "Accept" the change?
Does a change to the condition pack at the company level create individual changes on all rules where the pack is used (Changes that need to be added to a library and published)? Or are they just automatically added into the next build?
Can individual rules make modifications to the conditions in a pack or are they un-editable at the individual rule level?
Similar to #2, if you choose to copy an individual component, it seems to make sense that you'd be able to make modifications to the new thing after copying it, but if you choose to inherit it it wholesale (picking from the "pool"), could you then make modifications to the new instance, or is it set to whatever is in the pool? And would it make sense to have different behaviors based on whether you copied or inherited?
These are some of things we're trying to figure out, let us know what you think.
I think that before we can answer this, we'd have to answer, "Where would one go to create and edit a condition pack?" It seems like a condition pack would need to be its own thing and would live at the same level as data elements, rules, extensions, etc.
Perhaps a condition pack is a special type of data element which can only return a boolean value. Then it could be used within a Value Comparison type condition.
I see it topping out at the property level. If changes were made to the pack, I would want that change to affect everything that uses that pack when a library is built that includes the changed pack. If the pack were to be implemented as a new kind of data element, then the propagation would follow the rules of data element changes today.
I think this is the same as question #2.
I would want them to be un-editable at the rule level. If you needed, you could certainly add conditions or exceptions at the rule level (in addition to the pack) but you should not be able to modify the pack at this level.
I think that it might make sense to copy a pack at the top level, but a copy of a rule that referenced a pack would be a new object with an identical reference.
I actually have a similar problem with referencing in another project I am working on. I also didn't find the perfect solution yet, else I could share it here. But I like stewarts ideas and add my two cents:
Why only discuss about conditions?
Events: I think events don't really need to be shared within a property but in our case, where we have two websites built on the same components within AEM and also have the same datalayer, it would make sense to have them on company level. But I can live with events not beeing shared
Actions: I have two cases where I have the same actions for multiple rules:
"Page Load" for static pages and "App Init" for SPAs. The later replaces the former if the page contains an SPA (usually an Angular or Vue app).
Video Milestones: For each milestone I want to track a generic "milestone reached" event and time delta numeric event. As well as an evar with the video name.
Storing them in a separate list like Data Elements is a good idea.
For selecting them, within a rule, I suggest to have a "fork" on the add button, where you can choose to select an existing or to create a new one just for this rule, as it is now. And this is how I would separate them:
If you create a Condition or Action on property level, a change will be reflected in all rules, maybe provide a list of all rules that use it, so they can be reviewed
If you create a Condition or Action within the rule, it is only visible there.
I actually do this but with a data element of type custom code and then make a condition of value comparison on each new rule referencing the data element.
Would it be hard to simply make a data element of type "rule component" for events/conditions/actions and then have an easy access for them in the rule-building page?
