I am using nested reusable elements to simplify my workflow, but I have found a very specific issue.
I use an RG that contains REs (I know, I’m sorry!) and those REs display changes depending on the state of the container, which pulls from a condition that looks at the value of specific columns in a row of the database.
To make it more simple: If a person liked Red, Green or Blue, the RE changes from a cross to a tick.
This works without issue but I have stumbled into a new issue.
If the RG updates (a person is added or removed) the states of the REs do not update.
For example:
Tom likes Red
Alice likes Blue
Sam likes Green
If I remove Alice, suddenly Sam likes Blue, not Green.
I am using a “Do when condition is true - Every time” to set the RE values based on the row value, but they don’t update when the RG updates.
I can fix it by manually writing conditions for every element, but that kind of defeats the object.
check out the free plugin called orchestra…it allows actions to be triggered inside of an RG from outside, which means it can trigger actions to update the reusable elements states from outside of the rg…but, you might not need it.
Share screen shots of the RG and its elements, specifically where the element is that allows a user to be removed.
OK lets look at the RG route first. Maybe it’s best that I explain my setup.
This process is actually for recruitment.
Each person can be a Lead or Onboarding, Active or Inactive and Open or Closed. However, Lead and Onboarding are boolean, as they are exclusive from one another, but not the other categories. Active/Inactive is another boolean, also exclusive, and Open/Closed is a third boolean. It complicates things a little, but it works and allows me to use toggles for a simpler UI/UX.
For someone to move from Onboarding to Active, there’s a counter that counts the steps completed through the recruitment journey.
Once a person completes the 5 ‘checks’ they are automatically moved out of the Onboarding pool and into the Active pool in another window. They are technically not ‘moved’ anywhere, they just don’t fit the search criteria anymore.
The RE and RG are simply there to speed up development and minimise elements, really.
The REs are the problem from what I can tell. All they do is check to see if the state of the RE is complete. If yes, change to green with the check mark, as in my earlier images.
Here are the 5 checks I mentioned above. They all work the same way, check to see if the state matches what it expects to see, check to see if the ‘evidence’ is in the database, if yes, change the state of the element.
Your RE needs to have type of content of Driver or at least have a parameter of type Driver.
No need for any workflow actions or custom states on the RE as it would have the content or parameter value of driver to match the RG cell Driver the RE is placed in.
So whatever changes you make to the DB on the driver, the RE like the RG is updated in real time, which requires no workflow actions or custom states as the update is tied to the data in the DB.
Your element in the RE just needs a condition to look at the content type or parameter driver values status to change to green or not.
Ah! That’s a much better way to reference the value held by each Driver. So all I will need to do is create a condition for all 5 [property] values of the RE?
