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.
It would be even better if you could reuse blocks of conditions. I'd also throw in a request for reuse of action blocks too.
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.
In my perfect world, there would be no bad wine.
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:
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: