Multiple Entities Within One License

If your company has multiple legal and/or geographical entities (e.g., you are a group that consolidates several subsidiary companies, or you are one company with branches in different countries that operate independently), you will need to decide whether to have just one license or multiple licenses. This article provides important information to help you decide between these options.

The single license option is usually more attractive at the beginning because it naturally means cost savings compared to multiple licenses. Although you can work with multiple entities within one account in ATS Recruitis, it is not possible to create multiple separate sub-entities with their own company ID, GDPR rules, etc. on one account. Therefore, you need to consider all implications of each option and specific preferences in your company's recruitment process.

In the following overview, you will learn how each option works and what their pros and cons are.

Single License Option

When to consider this option?

This option is possible if you want and can share a unified talent pool with single GDPR rules and if you can communicate within the company in one language with an identical set of processes, tags, etc.

Pros:

• Lower cost (you pay for only 1 license)
• Ability to have a single administrator for all entities and ensure consistent work across entities (recruitment flow, email templates, etc.)
• Reporting from one place with the ability to separate data for individual entities

Cons:

• Cannot have different GDPR rules for each entity
• If you need to use multiple languages, you will have many elements in the system duplicated just for language purposes (recruitment flow, tags, filter items, rejection reasons, response forms, etc.)
• If each entity uses different publication channels, all will be available to everyone

Typical examples of companies using this:

• Company is a group of smaller Czech startups where they want to introduce and enforce standardized processes and have only one place from which they manage HR processes.
• Company has a branch in the Czech Republic and Slovakia and they share unified processes.
• Company has branches in several European countries with central HR and communicates everything in English.

Whether multiple entities can have the same GDPR rules and whether you can share a talent pool must be confirmed by your DPO or the person responsible for GDPR matters in your company.

Multiple Licenses Option

When to consider this option?

This option is the only possibility if individual entities have different GDPR rules and if they cannot or do not want to share a common talent pool. In this option, each entity has its own license where they define everything exactly according to their individual needs - whether linguistic, procedural, or legislative.

Pros:

• Each entity can set everything exactly according to their needs and practices (GDPR, processes, publication channels, etc.)
• Each entity sees only their content
• No need to introduce "artificial" differentiators for various items in the system (tags, rejection reasons)

Cons:

• Higher cost

Even in the multiple licenses option, if you want to have only one administrator, you can do so by having one user with the administrator role having an account in all entities and switching between them - see this article.

Typical examples of companies using this:

• Company is a group of companies acquired through acquisitions that have their own autonomous rules and processes.
• Company has branches in 5 countries across Europe, where each speaks a different language and it is not possible to enforce one common language.

Practical Example of Setting Up Multiple Entities Under One License

Your company was created by merging two originally competing companies "Autodoprava Novak" and "Spedition Prochazka" and you want to work with a shared talent pool of candidates with a unified process.

During setup, you will primarily encounter these questions:

How to separate branches?

In the branch editing (link), you have the option to add details to each branch including its name, where you can specify the name of the given entity (in our case, whether it is "Autodoprava Novak" or "Spedition Prochazka").

When assigning branches to individual positions in position editing, you can easily distinguish between branches of individual companies.

How to separate positions?

To separate positions, you do not need to use specific names or codes in position names. For this purpose, ATS uses "Filter Items" (link to settings), which you can use to separate positions for individual entities.

Learn more about using and functioning of filter items in this article: Practical Use of Filter Items.

In our example, you would create a category "Company" with items "Autodoprava Novak" or "Spedition Prochazka". In position settings, you then assign the appropriate company to each position.

Filter items also have significance for filtering positions for career websites and data for analytics.

How to set up roles and permissions?

This depends largely on how much or how little you want to collaborate between individual companies.

Scenario 1 - "Central HR and Separate Companies"

• Create one user with the "Administrator" role for the entire group (only this person can configure company settings and sees the complete talent pool).
• For recruiters from individual companies, create users with the "HR Specialist" role (they can only see their positions that they created and candidates on them).
• If someone from individual companies needs to see the entire talent pool, create them with the "Senior HR Specialist" role (they see all positions and all candidates but cannot change company settings like an administrator).

Scenario 2 - "Individual Companies Are Equal"

• Select one administrator from each company so they can configure items from company settings (recruitment flow, filter items, rejection reasons, etc.).
• Recruiters will primarily have the "Senior HR Specialist" role and will see the entire talent pool and all positions.

How to handle logos in emails?

Email messages can generally have only one logo (each license allows using only one company logo), but within email templates, you can use a "trick" that, when disabling the company logo (or when using a group logo), allows using a specific company logo in the email body. In this article, you will find a description of such a solution.

How to connect to multiple career websites?

This can be done using filter items as described above in the section about separating positions.

When loading positions via API to individual career websites, simply use filtering via filter_id[] in the GET request for position listing, where you enter the filter item ID for each company.

Specific details can be found by your career website administrators in our API documentation for position listing.

How to separate data in analytics?

Again, the answer is filter items, which are part of data filtering across individual metrics and reports. It is important to know that although filter items primarily relate to positions, candidates from these positions "inherit" them. In our case, if I have one position with the filter item "Autodoprava Novak" and 2 candidates on it, then when filtering the candidate report by the filter item "Autodoprava Novak", these two candidates will be shown.

Practical Example - Adding a Second Entity Under One License

The situation where you want to have multiple entities under one license in ATS Recruitis may not arise at the beginning of the collaboration but may occur when one license for one entity has already been running for some time.

In such a case, if you decide on one license, you will face a situation where one entity already has everything set up according to its needs and the second one will enter into this, requiring certain adjustments to be made to the existing entity as well.

Below is an example checklist that you should go through, covering individual key settings and system items that need to be thought through for integration. For easier orientation, we provide an example where you have an existing Czech entity "CZ" and want to add a Slovak entity "SK" to its license (language differences clearly define the decision-making).

GDPR Compliance Verification

• This is not so much about whether the GDPR consent text is identical, but about how many years the consent is granted for.
• Within one license, you cannot have multiple GDPR rules, thus not multiple maximum consent duration lengths.

Adding SK Branch Employees

• Initially, just add one colleague from the SK branch with administrator rights, who can then add more users from the SK branch.
• For selecting an administrator, it is also important whether they can help with setting up items that will be solely for the SK branch.
• Discussion and mutual cooperation will also be important when choosing whether to keep certain settings as one or create two sets (more in the description of individual items below).

Setting Up Filter Item Clearly Defining CZ and SK Entity Positions

• Since you will have a shared talent pool, having one key filter item that clearly separates your data is useful for orientation in positions and candidates.
• For example, create a category "Branch" with values "CZ" and "SK", which you set as mandatory so it must be set when creating a position.
• Also consider whether some positions can be shared by both entities, or whether you can always select only one option (set the "Multiple items can be selected" option for the filter item category accordingly).
• Retroactively set this for all CZ positions, and for SK positions, it will be gradually added as each position is created.
• This filter item can be used not only within ATS Recruitis for filtering positions in the UI but also, for example, via API for filtering positions to individual entity career pages or filtering on shared career pages.

Branches

• The branch (or multiple branches if the SK entity has more) can also be set up immediately by the SK entity administrator.
• For branches, it is important that besides the address, they also contain the branch name.
  • This is then displayed as the company name, e.g., in interview invitations, etc.
  • So, if the Slovak branch is called, e.g., "Recruits.io, s.r.o. Slovakia" and the Czech one "Recruits.io, s.r.o. Czech", you want the branch names to appear correctly according to location and not confuse candidates.

Response Form Settings

• Response forms will be used for communication with candidates, so they need to be set up specifically for the SK branch in Slovak.
• An important part is also creating Slovak GDPR consents, which are then added to the form.
  • GDPR consent text is not just about translation into another language; GDPR implementation may differ slightly in another country or even within a given branch.
  • If branches are also different legal entities, e.g., within a group of companies, according to GDPR wording, it should also be distinguished for which entity consent is given. Therefore, if you have 2 entities, the form for CZ should have 2 GDPR consents - one for CZ and one for SK.
• Here is a link to an article with a practical example of setting up a foreign position including form and GDPR consents.

Email Templates

• Email templates are again something you will need to set up for the SK entity anyway.
• If both entities have a unified logo, just use the one the system offers in the email header. If logos differ, you need to disable the main one and insert logos into email templates as images (e.g., under the signature).
• Do not forget about system messages like "Automatic Response", which must be in Slovak for Slovak job ads.

Recruitment Flow

• This is one of the items where you need to consider whether to keep one shared flow or add a special one for the SK entity.
• In most cases, the option to have a separate flow for SK will likely win.
  • Besides simplicity (not needing bilingual state names or laboriously inventing universal names or abbreviations), it is also practical from an analytics perspective, where data will be separated through flow filtering.
  • It is also likely that each entity will have more than 1 flow and different numbers (e.g., according to position types they fill, different work with hiring managers, etc.).

Rejection Reasons

• Rejection reasons are the only item that cannot be categorized (like tags or filter items), so you must always have only one set.
• Individual items could certainly be duplicated by language, but this could negatively impact the UI (having to scroll long before finding a reason at the end of the list) and also statistics (the same reason would exist twice).
• Companies often solve this by choosing one common language (e.g., EN) or naming items bilingually (e.g., "Insufficient education / Nedostatocne vzdelanie").

Tags

• Tags offer the option to create for all, or just for some, your own category, e.g., "Skills - CZ" and "Skills - SK", with your items to use for your positions and candidates.
• But here too, it will probably be more practical to have one set and expand it where something from the SK entity is missing, as this will not create duplicates for reporting or searching in the talent pool (although this depends on how collaboration and sharing within the talent pool works between two entities and separation may be desired).

Filter Items

• Besides the filter item mentioned above that controls position affiliation to an entity, you may have, and probably will have, other categories.
• Filter items have the same logic and structure as tags - they are grouped into categories, and you can create unlimited amounts, some shared, some individual for each branch.
• Similar to tags, consider here how much you want the position pool connected or separated and whether it is better to strictly separate and duplicate filter items or combine them.

Job Offer Templates

• If you use offer management within ATS Recruitis, you will also need to create job offer templates in the SK entity language, with their description, benefits, etc.

Publication Channels

• The SK entity will likely have different publication channels than the CZ entity.
• Channel setup is independent and can have as many as you want, even duplicates, if, for example, both entities use a job portal under their own accounts and want to keep it that way.

Candidate Import

• The SK entity will naturally also want to transfer their existing candidates from their current system to ATS Recruitis.
• In a situation where these candidates are being added to a running CZ instance, it is important during import to ensure these candidates are clearly marked with a source (e.g., "Import SK") or a tag (if each candidate also has their original source).