Hi there, I’ve read all the posts and tried everything, but I can’t solve this problem.
Basically, I’m running a scenario where I end up with an array aggregator module with 6 operations, but I would need to have only 1 operation with 3 bundles, or the following filter would not work.
This is the full scenario:
This is the last array aggregator module with the 6 operations results:
This is the settings of the array aggregator module:
So, obviously, the array aggregator doesn’t aggregate the bundles across operations, but repeats the bundles in the same amount of operations.
The operations are 6 because the previous module is checking that 3 candidates have in their skills array the 2 mandatory skills that are iterated in a previous module = total of 6 operations necessary.
What I’ve tried:
- Set as a source module of the array aggregator a previous module with only 1 operation in it. It works just fine, but this has the unintended consequence of eliminating all the variables in between the array aggregators and the source module for future use in following modules. I’ve tried to get the variables using the module number e.g. 12.candidate_skills, but it doesn’t work
- Use a set multiple variables module after the array aggregator. Still producing 6 operations
- Use an aggregate to JSON module before the array aggregator. Still producing 6 operations
What I’m trying to do sounds pretty basic, but it looks like the answer is not so simple. Any help is greatly appreciated.
I’m attaching the blueprint here for your reference.
blueprint (2).json (62.6 KB)
Hello @cant_make_it,
Welcome to the Make Community!
So in module 79, what is that iterating?
That appears to be the module that’s producing 6 bundles and causing module 104 to run 6 times. I’m not sure I fully understand the issue and what you’re trying to accomplish, but you can try setting module 79 as the source for module 105 aggregator and see if that helps.
3 Likes
Thanks @Donald_Mitchell for the warm welcome and coming to the rescue!
In module 79, I’m iterating the job_skills from module 2, mapping out only the ones that are mandatory. In theory, only 2 bundles should be generated in this case (because I’ve got only 2 mandatory job_skills); but, since in the module before (55) I generated 3 bundles, in module 79 I end up with 6 operations. I had tried to put the module 79 just after module 2, but the effect on operations was the same, because any following module’s number of operations would be multiplied by 2 (as in the number of bundles in module 79).
To clarify what I’m trying to achieve: I get job data from Bubble, including an array of collections of job_skills that are mandatory (or not). Then I get candidate data from Bubble, including an array of collections of candidate_skills. One item that both collections have in common is the skill_id. So the filter in the router tries to filter in only the candidates who possess all the mandatory skills related to the job. Without going into the details, I need to do “if array candidate_skills_skillID contains all items in array mandatory_job_skills_skillID” then pass, otherwise fail. After weeks of work, I discovered that “contains all” function doesn’t existing in make.com; neither “intersect” or “filter”, through which I could have used the “length” function to assess if the number of items in the array would match. As you can see, I went through a rookie hell. I ended up comparing each candidate’s candidate_skills_skillID array to one single mandatory_job_skills_skillID bundle at at time, aggregate the individual checks into arrays of checks by candidate, and finally check in the route filter if any of the array items “is_present” is false through a “text (not array) operators: does not contain false”. Array operator won’t work, because it’d check only the first item of the array items “is_present”, instead of all them. By the way, it was working, because I used as source module for the final aggregator module 1, where there was only 1 operation, which seems to be the only way to reduce operations down to 1 (nothing else has worked to reduce operations). The problem is that then I need to calculate the score for each candidate based on other variables that won’t be possible to select anymore because the final aggregator module would make all variables in between it and the source module “disappear” from the variables selection panel.
I’ve used your solution and it appears to be a good compromise, the number of operations in the final aggregator went down to 3 (as in the new source module, which outputs a number of operations equal to the number of candidates still at play). This should guarantee that this patch works across cases. Many thanks!
p.s. I find the lack of functions pretty underwhelming, you have to go through too many gimmicks to do simple things!
I think the reason it is still producing 3 bundles is because of the Group By option you have filled out in the Aggregator. It’s a separate operation for each group.
Thanks @Donald_Mitchell . I’ve tried to remove it, but same result. From what I’ve observed the number of operations in the destination module is the product of (operations in source modules) * (bundles generated in new module), and there is no way around it. I’m new to make.com, and quite likely there’s something I’m missing, but the lack of an aggregator that works across operations and can group by e.g. an object id across modules, is quite surprising. And it results in more operations… higher cost. Anyway, thanks again! Now I’ll work on the score and my first module has got 15 operations! Probably better if I hire an expert (unless make.com is not a good choice for these scenarios).
