I’m trying to use the minus list filter to identify an item that has been removed from a list but I don’t know what I’m doing wrong.
What problem are you having exactly?
I imagine that this workflow will timeout very often, as it is quite inefficient.
You are retrieving ALL C-skillsets in the search, and then applying a filter on each one of them individully, which is an extremely heavy operation.
There must be a more direct way of fetching the desired C-Skillset without using a search that fetches all items in a table.
I have a repeating that shows a list of Skillsets.
It also shows how many Employees have those Skillsets.
I need the ability to add an employee to the list from the Skills Register, whilst also having the ability to add / remove a Skillset from an Employee’s profile page.
Two things are updating. The Employee has a list of Skillsets and the Skillset has a list of Employees.
If a user adds or removes a Skillset to an Employee, I want to update the list of Employees on the Skillset.
The initial search function should filter down the list to Skillsets that are linked to the Employee.
The final filter is only applied to Skillsets that contain Employee Before Change.
Thanks for the extra information and context. So i’m assuming the problem is that the employee is not being removed from the list.
Biased Opinion: I personally avoid Trigger workflows if it is possible to use an API workflow instead. You could have a Add Skillset API and Remove Skillset API and it would generally be more straight forward. Having said that, I’m sure Trigger workflows can also do the trick.
Check the server log to see what exactly is happening in the Trigger workflow. Is the “only when” condition passing? Is the trigger event triggering? Are you accidentally adding the employee back to the skillset in a later workflow step?
Unfortunately, I have to use a DB trigger.
I have a workflow action on the frontend that sets a list of things, so it’s not like one item has been removed from or added to the list.
Just bumping this thread in case someone knows how to fix this DB trigger… 
That RG, what is its source? A search or could it be a state? If you look at the database, does the change actually happen?
Did you try adding a send email action to the trigger to see if it triggers it?
Wait, are db triggers available in your Bubble plan?
Thanks for dipping you toes into this one Rico.
This is a backend workflow that will update the list of Employees on the Skillset.
That repeating group is just an example of where the Skillset has a list of Employees.
I’ve probably made things more confusing.
Thing “Employee” has a list of “Skillsets”
Thing “Skillset” has a list of “Employees”
If the Employees list of Skillsets is changed, the modified Skillset also needs its list of Employees updated.
I can currently update the lists when I add a Skillset to an Employee or add an Employee to a Skillset. This works without any issues. I basically find the Skillset that was added last to “Employee now”.
The problem occurs when I need to remove an Employee.
That’s even weirder. I think – if I were you – I would try to add all types of debuggers to see what’s working and what’s not working. My go-to debugging technique for backend workflows is to add a step that sends a message to Slack and send as much information as possible.
Also, might be useful here, I’ve once tried to keep 2 data types in sync and… boy, that was tough. Probably a skill issue on my part. Anyway, what I decided to do instead was NOT try to keep them in sync. In your case, I think I would simplify with
- Employee data type
- skill list
And remove the employee list from the skill.
- Skill data type
employee list
Anytime you need to see who has those skills, you do a search. This way you’re reducing and simplifying the db operations.
1 Like
Sorry for the late reply to this one.
Your suggestion to use notifications led me to discovering that the issue was elsewhere.
A great suggestion that I’ll use in for all my future troubleshooting.
Thanks Rico
1 Like
This topic was automatically closed after 70 days. New replies are no longer allowed.