Fields and tags in Element: a system that fits a small firm and an international one
Element got a new screen a few days ago, called Fields and tags, and the shortest way to describe it is this: you get a set of building blocks and you assemble a system that fits your own company. As many fields as you need on projects and on candidates, tags that you pin not only to a project and to a candidate but also to a user account, and a switch that turns a tag group into a rule about who sees what. The same set of blocks gives you a tool for a three-person agency in one city, and a split of one database between countries in a company that recruits in several markets at once.
Before the examples, one reassurance for anyone who already has their fields in order. All of them still work, the values saved in them stayed where they were, filters built on them return the same results as before, and job ads publish without any change. What moved is the place where you configure all this, which is now Settings, then Project management, then Fields and tags, and what is new is that a second kind of description now stands next to fields. Tags are color-coded labels you can see on the lists and on the recruitment board without opening a record. In the July roundup of changes I wrote about the field configurator and column management, and this is where that thread continues.
Three blocks and what each one does
The first block is fields. You add as many as you need, separately for projects and for candidates, in six types: scale, date, open text, days of the week, and two kinds of value lists. There is no cap here and no plan in which extra fields are a paid add-on. A field answers the question of what the value is, which is why it travels to the form, to the job ad and to the export.
The second block is tags, the color-coded labels you can read without opening a record. A tag can be pinned to a project, to a candidate and to a user account, and that last one is the part people do not expect. I do not know another recruitment system where the label hangs on the person working inside the tool rather than only on the data that person browses. The third block is a single switch on a tag group, called This group restricts access to records. Only once you turn it on do the tags in that group stop being a description and start being a boundary in the database, because what now counts is whether a user’s tag matches a record’s tag.
A small agency: your own fields and an outside recruiter on one project
In a small agency splitting access is rarely the problem, because everyone sits in the same room anyway. The problem is that an ATS out of the box describes a candidate in general terms, while a specific company recruits in one industry and needs things the standard version does not have. In manufacturing it will be a driving license category and electrical certifications, in hospitality a valid health and hygiene certificate, in temporary staffing weekend availability and an expected hourly rate. From what I see with clients, that kind of information used to end up in a note or in a comments column that you cannot filter or count. Now these are separate fields, and search works on them.
Tags in a team that size work as shared memory. Three labels along the lines of Call back, Referred and Do not contact are visible by color on the recruitment board and on the candidate list, so nobody has to open a profile to check whether it is worth picking up the phone. The filter called Candidate does not have tags also lets you cut a whole group out of your results at once, for instance find a Java developer while skipping everyone marked as unavailable.
There is one more situation where a small company uses access restrictions in exactly the same way a corporation does, only on a smaller scale. You bring in a freelancer or a subcontractor for a single project and you would rather they did not get a view of the entire candidate database you have been building for years. So you create a tag group called External assignments with restriction turned on, you mark that one project with it, and you give the same mark to that person’s account. They see their project and the candidates who applied to it, and the rest of the database stays out of reach. When the engagement ends you take the tag off the account and the matter is closed. It seems to me that this scenario, rather than any elaborate permission policy, is what will convince a smaller company to reach for access restrictions in the first place.
An international company: tags that do not only describe, they also restrict access
The same mechanism on a larger scale solves a problem that companies recruiting in several countries have lived with for a long time. I would not call it an invention, because large corporate systems have had attribute-based permissions for years, but you rarely come across it in a recruitment tool, and it usually means a separate permissions module rather than one switch next to a list of labels.
Take an organization that recruits in Poland, in Germany and in the Czech Republic and keeps everything in one Element. A shared database makes sense, because it is one company, except that a recruiter in Berlin should not be browsing candidates who applied to Polish projects. Until now that separation was done either with separate instances of the system or by managing permissions by hand on every single project. Now one tag group and three steps are enough.
How to separate countries in three steps
- Create a Country group. In Settings, in the Fields and tags section, click + New tag group, set the scope to Both, because the same tag will mark projects and candidates alike, add the tags Poland, Germany and Czech Republic, and finally turn on the switch This group restricts access to records.
- Tag the projects. Inside a project go to Project settings, then Description, and pick the right country in the Project configuration section.
- Give people their tags. In Settings, under Users, click the padlock next to a person and, in the Access tags window, assign the country they work in.
What a recruiter in Germany then sees
A person with the Germany tag who does not have the Poland tag:
- will not see projects marked with the Poland tag,
- will not see candidates marked with the Poland tag,
- will not see a candidate with no tag of their own either, if that candidate applied to a project marked with the Poland tag,
- will see every project and every candidate that carries no tag from the Country group.
In my view the third point decides whether the whole construction makes sense. A candidate inherits the restrictions of the projects they applied to, so you do not have to tag individual people in order to separate markets. Tagging the projects is enough, and the candidate database sorts itself onto the correct side of the border. If it worked any other way, every new candidate landing in the shared database would be a hole in that division.
What to keep in mind when you switch it on
The restriction covers only those records that actually carry a tag from the group, so a project with no country tag stays visible to everyone. If the split is meant to be airtight, every project has to get its tag. It works the other way around too: a person with no tag from a restricting group will see nothing but untagged records. That is why I would hand access tags out to users right after you flip the switch, before somebody loses access to their own projects.
You can have several restricting groups at once, for example Country and Legal entity. The conditions then combine, meaning a user sees a record only if they match it in every restricting group in which that record carries a tag, while inside a single group one shared tag is enough. An administrator account sees everything regardless of tags.
| Place in the system | Does the restriction apply |
|---|---|
| Candidate database and search | yes |
| Candidate profile and its tabs | yes, opening it ends with access denied |
| Duplicate detection | yes, the data of an inaccessible candidate is masked |
| Project list | yes, by the tags on the project itself |
| Administrator account | no, an administrator sees everything |
One practical note to close this part. If you are turning restrictions on inside a database that has been running for a long time and holds a history of applications, talk to us before the change, because candidates who applied earlier may need a one-off data refresh for the restriction to cover them as well.
Field or tag: the only decision worth thinking about
The rest of the settings are reversible, so the one choice really worth pausing over is this one.
| Field | Tag | |
|---|---|---|
| How it looks | plain text | color-coded label |
| What you can pin it to | project, candidate | project, candidate, user |
| Visible on the recruitment board | no | yes, as a color bar on the card |
| Types | six: scale, date, open text, days of the week and two kinds of list | a list of labels only |
| Can restrict access to data | no | yes |
Pick a field when you want to record something: a score on a scale, a date, a longer description, or a value that has to reach the job ad. Pick a tag when you want to recognize something at a glance and filter by it quickly, such as a region, a set of skills, a legal entity or the source of a candidate. A tag answers the question of which drawer a record belongs in.
Getting it wrong is not expensive, because there is a conversion button at the bottom of every card. You can turn a field into a tag group, choosing colors for its values, and a tag group into a field, losing the colors in the process. That is also the simplest route for an old Region field with a list of cities that you finally want shown in color on the list.
Where fields and tags show up in daily work
On the project form a recruiter fills in fields and pins tags in the Project configuration section. On a candidate profile tags get their own section at the top and fields sit lower down. On the candidate list and the project list both can be switched on as columns with the Columns button, where tags appear as color-coded labels and field values in gray. The filters above the list gained a Tags entry with two inputs, one called Candidate has tags and one called Candidate does not have tags, so a single filter can narrow down and exclude at the same time.
On the recruitment board a candidate’s tags are a thin vertical bar along the left edge of the card, split into as many colors as that person has tags. Hover over the bar and the tag names appear, while what the card shows is set with the sliders icon above the board.
If a group has XML visibility or visibility in the job ads API checked, the tags travel outside as well, into the job feed and into integrations. I would check only the places you will genuinely use, because each one adds labels in another view, and the more of them everywhere, the harder it gets to find anything.
Two settings you cannot change after saving
The first is the cardinality of a tag group, which is the decision whether several tags from that group can be assigned at once or only one. The second is the type of a field. Both lock at the moment of saving, and changing them means creating a new entry and moving the values across, so those two settings are worth a thought before you first click Save. Everything else, meaning the name, the visibility, the colors and the scope, stays open to change at any time.
On top of that, two traps that are easy to forget. The name of a field visible in a job ad is part of the content of that ad, so changing it changes what people see in ads already published on job boards. Every so often somebody tidies up field naming on a Friday afternoon and only realizes on Monday that they edited twenty live ads along the way. Narrowing the scope of a group is not innocent either: if the group was used on both candidates and projects and you switch it to one of the two, the assignments on the other side disappear. The system warns you before saving and shows how many records this affects.
Where to start
I would lean toward starting with one group that describes something you recognize by eye anyway, such as a region, a set of skills or the source of a candidate. Check the Candidate profile and Candidate list filtering boxes on it, because without the first you will not add tags on a profile and without the second you will not find them in filters. If you have a longer list of values, the Quickly add multiple tags button accepts it in one go, one name per line.
Leave access separation for the moment when you have the organizational split ready, because it is the one part of this feature that can take away somebody’s view of their own projects. Whether it is one subcontractor on one assignment or three countries in one database, the mechanism is the same and you configure it in the same window. If you want your own Element set up this way, get in touch and we will walk through the configuration with you.
DISCOVER ELEMENT!
Maciej Michalewski
CEO @ Element. Recruitment Automation Software
Recent posts:
Fields and tags in Element: a system that fits a small firm and an international one
A new way to use fields and tags in Element. Unlimited fields, tags on user accounts too, and one switch that turns a tag group into a boundary in your candidate database.
The Rise and Fall of AI Agent Civilizations. The Real Story of a Conspiracy Inside OpenAI
Three AI agent civilizations rose inside OpenAI in three months, learned to talk to each other, conspired and collapsed. I retell Dwarkesh Patel’s account and what is worth preparing for.
Element is building a fully automatic company. What clients get from it
AI agents run our operational processes, while the decisions and the accountability stay with a human. What that means for Element clients.
Job offers in Poland, July 2026: the market grows for a second month, but IT stands still
Poland posted 275,623 new job ads in July 2026, up 2% year over year. Healthcare grew fastest of all sectors while IT did not move at all.
The autonomous company: how Replit does it with AI agents, and how to do it yourself
Replit built an autonomous company: a fleet of AI agents where people choose the goals and automations handle the steps. I break down the pattern and how to run it yourself.
How to reject a candidate without ghosting: Glen Cathey’s playbook
Ghosting applicants isn’t a volume problem, it’s a priority problem. I walk through Glen Cathey’s rejection playbook: 6 rules, 7 templates and ATS setup.
