🗣️ For context, one of our Mercury Community members asked the following question:
" Hi, is there a way to edit filters for a view in a code editor? Or maybe there's an easier option to do something: I'm setting up a group with 'field' -> 'does not contain' -> 'value' and I would like it to have an option to list the separate values as 'this' OR 'that' etc instead of setting it up manually for each value. Thanks! "
🧙♂️ This is what our resident Mercury Guru had to say...
So, to clarify the customer's query, they want to exclude records from their View that are tagged with specific Tags, and so the first place to start for this answer is to understand Tags and how they work.
Every Mercury customer can create a list of Tags that can be used to assign to records, to allow that record to be differentiated from others, most commonly for searching purposes.
As an example, some customers tag Candidates with their desired location, particularly if they're willing to relocate. When running a search, the Mercury user can then include that Location Tag in their search criteria, in order to find those Candidates who have been tagged as prepared to work there.
There are many other areas where Tags can be used, to allow for categorising, organising and differentiating records, and with our AI functionality taking this further, please do reach out to your Mercury Customer Success Manager if you aren't currently taking advantage of this.
When it comes to creating Tags, you can create one long list of all the things you want to use, or you can choose to organise them into a folder-like structure. This is where the term Leaf and Node come in to play.
In short, a Leaf is something that can be assigned or 'picked', like you would pick a leaf from a plant, and a Node is a folder-like container, like a branch to which a leaf belongs.
Let's use our Location example again. We could just have a list of all the different Countries that a Candidate could be prepared to relocate to, in a singular list like below:
Australia
Brazil
Canada
Columbia
France
Germany
Japan
UK
US
Each of these Tags would be a Leaf, and thus could be assigned to our Candidate record.
Perhaps we would prefer to organise the list into their respective Regions, and so could create 'EMEA', 'APAC', 'AMER' as Tags that are set as Nodes, and in turn, treated as a 'Parent Tag'. This may look something like this:
AMER
AMER > Brazil
AMER > Columbia
AMER > US
APAC
APAC > Australia
APAC > Japan
EMEA
EMEA > France
EMEA > Germany
EMEA > UK
As a Node, the Tag can't be added directly to the Candidate record, but our new Mercury Search will allow you to return results based on the node within which a Tag exists, meaning, inline with our current list, we could search for 'APAC' and return all Candidates who have been tagged with 'Australia' or 'Japan'.
We may, however, want to drill down further, and perhaps assign which State a Candidate is prepared to relocate to inside of the US. In our example, the US is already a Leaf that can be assigned to a record, and we still want to keep that functionality whilst also having it as a Node with which to 'parent' additional Tags.
We can have Tags that are both, and this is exactly what we would do in this scenario; whilst creating our additional Tags for each State as Leafs, that are 'parented' by the US Tag which is both a Leaf and a Node, so our new structure will look something like this:
AMER
AMER > Brazil
AMER > Columbia
AMER > US
AMER > US > Alabama
AMER > US > Florida
AMER > US > New York
AMER > US > Texas
APAC
APAC > Australia
APAC > Japan
EMEA
EMEA > France
EMEA > Germany
EMEA > UK
With the US still being a Leaf in its own right, we can still tag people directly with this, as there is sometimes reason to, despite the fact we can search for 'AMER' in Mercury Search and return people who have been tagged with Texas.
🌟 So now, to finally answer the Customer's question...
They want to exclude records from a View that have been tagged with any of the 50 States.
Instead of the above, the Customer had a Node of 'Location' parenting all of their locations, but the Tags for each US State had been created directly beneath 'Location' and so the Customer had to add a filter for each of the 50 States one by one as a 'Does not include' on their View.
Therefore, the solution we explored was to change the Tag setup to firstly create a 'United States' Node and then to associate all 50 State tags with this as their Parent Tag. To implement this in to our above example it would look something like this:
Location > AMER
Location > AMER > Brazil
Location > AMER > Columbia
Location > AMER > US
Location > AMER > US > Alabama
Location > AMER > US > Florida
Location > AMER > US > New York
Location > AMER > US > Texas
Location > APAC
Location > APAC > Australia
Location > APAC > Japan
Location > EMEA
Location > EMEA > France
Location > EMEA > Germany
Location > EMEA > UK
When excluding items from a View it isn't always straight forward, particularly in this case, as there are many Tags that can be associated to a Candidate record, and so simply saying related Tag > 'Parent Tag does not contain AMER' would only work if Candidates were only tagged with a singular Tag as that would be true.
However, given that the customer's Candidates are tagged multiple times, this doesn't work, as any other Tag would make this statement true. With this in mind, we have to expand the criteria to include more 'True' statements, and so the solution is to have criteria in the View stating that the Candidate has Related Tags, and that that Tag has a full name that includes and excludes them in one line, and so the final criteria on the View looks like this:
Related Entity
Tags > Contains Data
- Full Name > Begins with > Location
- Parent Tag > Does not equal > AMER
So to summarise, this criteria it is saying the records in the View must have a Tag associated with the record. That Tag must then also have a Full Name that begins with 'Location' but that same Tag must not have the 'AMER' Parent Tag associated with it.
For more ways in which you can take advantage of Tags, or how the new Mercury Search really takes advantage of these and combines with AI functionality, please reach out to your Mercury Customer Success Manager.
Mike Jones - Mercury Training Consultant
🌐 Do you have any questions around this?
Feel free to post any questions or feedback in our Mercury Customer Community about the content or advice in this article, and we will help you.