Your existing fields keep working. The values you saved are still there, filters based on them still run, and job offers publish exactly as before. Nothing needs rebuilding.
Two things changed. First, fields look different and you configure them in a new place: Settings → Fields and tags. Second, tags arrived: colour-coded labels you can read off a list or a recruitment board without opening anything.
Both kinds live on one list. Tag groups have a green edge and show their coloured labels right under the name; fields have a blue edge and show only the number of values.
Field or tag: which to pick
This is the one decision worth thinking about. Everything else can be changed later.
| Field | Tag |
How it looks | plain text | a coloured chip |
Colours | none | every tag has its own |
Visible on the recruitment board | no | yes, as a colour stripe on the card |
Types | 6 of them: scale, date, open text, pick lists | a list of labels only |
Can restrict access to data | no | yes |
Pick a field when you need to record a value: a rating on a scale, a date, a longer description, or something that goes into the published offer. A field answers “what is the value?”.
Pick a tag when you want to recognise something at a glance and filter by it quickly: region, skills, legal entity, candidate source. A tag answers “which bucket does this belong to?”.
Choosing wrong costs nothing: a field converts into tags with one button, and back again. More on that below.
The difference on a project form. “Region” is a tag group, so you get coloured chips you add by typing. The field below is a field, so you get ordinary radio buttons.
Where to configure it
Settings → Projects management → Fields and tags
The “Fields and tags” entry sits in the “Projects management” section of the settings menu.
Four controls at the top of the screen make a long list manageable:
the search box looks through group names, tag names, field names and the values themselves; type “Region” and the list keeps only what matches;
the “Tags (2)” and “Fields (6)” chips hide one kind so you can work on the other; hidden entries come back with the “Show” button;
the All / Candidate / Project switch narrows the list to what applies to candidates or to projects;
the “+ New tag group” and “+ Add a field” buttons.
Neither button opens a dialog. Each one adds a card to the list, ready to fill in. You save every card separately, and saving one never touches the others.
Creating a tag group
A tag group collects labels of one kind, such as “Region”, “Skills” or “Candidate source”. The tags are the concrete values inside it: Warsaw, Berlin, Prague.
Click “+ New tag group” and fill in the card. Below is the same card already filled in, using the “Region” group as an example:
A tag group card in edit mode. The “This is how recruiters will see it” preview updates as you type.
Tag group name. Recruiters see it as the heading above the chips.
Where to use this group. Candidate, Project or Both. This decides whether the tags can be picked on a candidate, on a project, or in both places.
Where this group is visible. Eight places to tick:
Option | What it does |
XML visibility | tags reach the XML feed of job offers |
Dashboard filtering | they become a filter on the dashboard |
Candidate list filtering | they show up in the candidate database filters |
Project list filtering | they show up in the project list filters |
Project list visibility | you get a column with these tags on the project list |
Project list searching | the project search takes them into account |
Candidate profile | a section with these tags appears on the profile |
Job offer API visibility | tags go out through the job offer API |
Tick only what you will actually use. Every tick puts the tags in one more place, and the more places they appear, the harder anything is to find.
How many tags from this group can be assigned. Multiple or Only one. Choose “Only one” when the tags rule each other out, for example Level: junior / mid / senior. Nobody is a junior and a senior at once.
You cannot change this later. Once the group is saved, the multiplicity setting is locked. Changing your mind means creating a new group and moving the tags into it, so decide before the first save.
This group restricts access to records. The switch for groups that decide who sees what. The first example below covers it in detail.
Tags in this group. Type the labels here. Each one has a colour dot on the left, a usage counter on the right, and icons to archive or delete it. If you already have a list, use “Add many tags quickly” and paste it whole, one name per line.
Close the card with “Save group”.
Creating a field
Click “+ Add a field”:
A new field is added to the list as a card in edit mode. You pick the type from a row of six buttons.
Field name. This is the text a recruiter sees when filling in a project.
Where to use this field. Candidate, Project or Both.
Field type. Six options:
Type | When it helps |
Multiple values | a list where several entries can be ticked at once |
Single value | a list where exactly one entry is picked (yes/no questions too) |
Scale | a rating, for example priority from 1 to 5 |
Week days | availability on particular days |
Open text | room for any description |
Date | a specific day from the calendar |
The type is locked after saving too. Changing it means creating a new field and moving the values across.
Where this field is visible. The same eight places as for a tag group. Watch one of them: a field visible in the job offer reaches the job boards, so renaming it changes the content of offers that are already published.
Available only when the project has a tag? “No” by default, meaning the field appears on every project. Switch it to “Yes” to show it only on projects carrying a chosen tag, for instance a single market.
Values to choose from. The list entries, added with “+ Add a value”. Field values have no colours; only tags do.
Converting a field into tags and back
Nothing is decided permanently. At the bottom of every card there is a conversion button:
on a field, “Convert to a tag group” turns the field values into tags and lets you pick their colours;
on a tag group, “Convert to a field” does the reverse, so the tags become ordinary values and lose their colours.
This is the right route when you have an old “Region” field holding a list of cities and you finally want to see it in colour on the list.
Example 1: countries, or who sees whose candidates
Say you work three markets and you want a recruiter in Germany not to browse candidates from Polish projects. One group setting does this: “This group restricts access to records”.
Step 1. Create the “Country” group
Go to Settings → Fields and tags, click “+ New tag group” and set:
Name: Country
Where to use this group: Both, because the same tag will mark projects and candidates alike
Where this group is visible: tick “Candidate list filtering”, “Project list filtering” and “Candidate profile”
How many tags can be assigned: “Multiple” if a project sometimes runs across markets; “Only one” if it always belongs to a single country
Tags in this group: Poland, Germany, Czechia
Finally turn on “This group restricts access to records” and save the group.
The “Country” group with access restriction switched on. The system warns immediately that users without a tag from this group will lose access to records carrying one.
Step 2. Tag the projects
Open a project, go to Project settings → Description and, in the “Project configuration” section, add the right tag in the “Country” field, for example Poland.
Step 3. Give users their tags
Go to Settings → Users. Each person has four icons next to them; click the padlock.
The padlock next to a user opens the “Access tags” dialog.
The “Access tags” dialog lists your groups. Give the German recruiter the Germany tag in the “Country” group.
The “Access tags” dialog. Tags are granted separately for each restricting group.
What happens then
A recruiter holding Germany but not Poland:
will not see projects tagged Poland;
will not see candidates tagged Poland;
will not see a candidate who applied to a project tagged Poland either, even when that candidate carries no tag at all. A candidate inherits the restrictions of the projects they applied to;
will see every project and candidate that carries no tag from the “Country” group.
That last point matters: the restriction only bites on records that actually carry a tag from the group. An untagged record stays visible to everyone. If you want a watertight split, every project has to get its country tag.
Someone with no tag at all from a restricting group sees only untagged records. After enabling the switch, assign tags to everyone who is meant to work a given market, or they will lose access to their own projects.
Several restricting groups at once
You can have more than one, say “Country” and “Legal entity”. The conditions then stack: a user sees a record when they match it in every restricting group where that record carries a tag. Within a single group, one shared tag is enough.
Where the restriction applies
Place | Applies |
Candidate database and search | yes |
Candidate profile and its tabs | yes, opening the profile is refused |
Duplicate detection | yes, an inaccessible candidate's details are hidden |
Project list | yes, by the project's own tags |
Recruitment board inside a project | no separate filter; it is protected by the user not seeing the project at all |
Administrator account | sees everything, restrictions do not apply |
If you switch restriction on for a database already in use, talk to us first. Candidates who applied earlier may need a one-off data refresh before the restriction covers them as well.
Example 2: candidate skills
The second common use for tags is skills: marking candidates with technologies and pulling everyone who knows a given one straight out of the database.
Step 1. Create the “Skills” group
In Settings → Fields and tags click “+ New tag group” and set:
Name: Skills
Where to use this group: Candidate
Where this group is visible: tick “Candidate profile” and “Candidate list filtering”. Without the first you cannot add tags on a profile; without the second they never appear in filters
How many tags can be assigned: “Multiple”, since a candidate usually knows several technologies
Access restriction: leave it off, these are plain descriptive labels
For a long list of technologies use “Add many tags quickly” and paste them all at once, one per line.
The “Skills” group scoped to Candidate, with the places the tags should show up ticked.
Step 2. Mark your candidates
Open a candidate profile. At the top, in the Tags section, you will find the group name and an “Add tag…” box. Start typing a technology and pick it from the suggestions. The chip appears immediately, and the cross on it removes the tag.
The “Tags” section on a candidate profile. The group name sits above the chips.
Step 3. Search candidates by skill
Open the candidate database and pick Tags from the “Filters:” bar. You get two boxes: “Candidate has tags” and “Candidate has no tags”.
Click the first one. The suggestions are grouped by group name, so you can tell at a glance which labels are skills and which are, say, a region.
Suggestions in the tag filter are grouped, which makes the right label easy to hit.
Pick Java to list everyone with that skill.
You can pick several tags at once. The system then returns candidates who have any of them, so Java plus Python gives you the sum of both groups rather than only the people who know both.
The second box, “Candidate has no tags”, works the other way and excludes the labels you choose. Handy when you want a Java developer but not anyone tagged “Do not contact”.
One filter narrows and excludes at the same time.
Two more routes
A column on the list. Click “Columns” above the table and switch on the “Skills” column. You then see everyone's technologies without opening a single profile.
Full-text search. Under the search box there is a row of scopes: name, email, phone, CV, notes, form, tags, projects, employer. With “tags” ticked, whatever you type is matched against candidate tag names as well.
Where tags and fields show up
On the project form. Project settings → Description → the “Project configuration” section. This is where a recruiter fills in fields and pins tags.
On the candidate profile. Tags in their own section at the top, candidate fields lower down, under the contact details.
On the candidate and project lists. As columns you switch on with the “Columns” button above the table. Tags render as coloured chips, field values as grey ones.
Tag and field columns on the candidate list.
On the recruitment board. A candidate's tags form a thin vertical stripe along the left edge of the card, split into as many colours as the candidate has tags. Hover it to read the names.
A card with its tag stripe on the left edge.
You control what the card shows with the sliders icon above the board, where “Tags”, “Days on stage” and “Application date” can be switched on and off.
Card content toggles on the recruitment board.
In job offers. If you ticked “XML visibility” or “Job offer API visibility”.
The other field filters
Besides the “Tags” filter, the bar above the candidate list holds two more entries tied to fields:
Candidate fields searches the values saved on the candidate profile. If the profile says “Department: Sales”, this is where you find them.
Project fields searches the values of the projects a candidate applied to. If they applied to a project marked “Project type: Recruitment”, this is where you find them.
The same field name can appear in both places, and that is not a mistake: once it describes the candidate, once the project they turned up in.
The sliders icon next to “Filters:” opens a dialog with every filter at once. It helps when you are building a query out of several conditions and do not want to click through the list one by one. “Clear all” lives there too.
The “All filters” dialog gathers every condition in one place.
Worth remembering
Two things lock after saving: a tag group's multiplicity (“Multiple” or “Only one”) and a field's type. Changing either means creating a new entry and moving the values. Everything else, including the name, visibility, colours and scope, stays editable.
Narrowing a group's scope drops assignments. If a group was used on both candidates and projects and you switch it to one of them, the tags disappear from records on the other side. The system warns you before saving and shows how many records it affects.
The name of a field visible in a job offer is part of that offer. Renaming it changes the content of offers already published on the job boards.
Only tags carry colour. If you want coloured labels on the list and on the recruitment board, you need tags, not a field.