Skip to main content
Business information is where you define your organisation’s shape: your legal company details, your offices, and the five values every employee record is tagged with — business unit, department, designation, grade, and cost center. It looks like a housekeeping screen. It is not. Almost every targeting rule in Empuls resolves against these values, so getting them right early saves a great deal of unpicking later. This page covers what each one is for, what breaks downstream when you change or delete one, and the order to set them up in. The screen lives at /home/companyinformation and is organised as seven tabs:
Tab and button labels are supplied per tenant, so the exact wording on your screen may differ from the descriptions here. The behaviour, the field limits, and the downstream effects are the same everywhere.

​
Why these five values matter more than they look

Every employee record carries their business unit, department, designation, grade, cost center, and location. Those values are pushed onto the employee’s profile and travel with it to every other Empuls service — which is why they turn up as targeting criteria and filters in places that have nothing obviously to do with org structure. Conditions in these modules support matching a value exactly, matching any of several values, or excluding a set of values, and multiple conditions can be combined with AND or OR logic. The practical consequence: a badly maintained org structure quietly breaks targeting. A budget rule pointed at a business unit nobody is mapped to funds nobody, and reports it as working.

​
Who can access this screen

Access is gated by the ACL key menuName.businessinfo. By default, only the Super Admin has access. Every other role — general admin, manager, employee, and any custom role — has none until you grant it, from the business and customisation section of access control.
Granting business information access grants full create, edit, and delete on the whole module. There is no read-only level, and no way to grant one tab without the others. A role you give this to can rename or delete a business unit that budgets and awards depend on.
A role without the permission does not see the module in the admin navigation. See Access control for how to grant it.

​
Set these up before you import anyone

The order matters, because employee imports and HRMS syncs resolve org values by name.
1

Fill in the company details tab

Company name, address, zip code, country, state, and your point of contact. This is the tab you land on. Nothing else depends on it, but it is the quickest to finish and it is mandatory.
2

Create your locations

Map each one to a country while you are creating it. The country is optional in the form but the wallet and redemption modules depend on it.
3

Create business units, then departments

Departments sit conceptually inside business units, so decide your business unit list first even though Empuls does not enforce a parent-child link between the two.
4

Create designations, grades, and cost centers

These have no dependencies on each other. Create the canonical list you actually want, with the spelling and casing you want to see in every report filter forever.
5

Only now import employees or connect an HRMS

With the values already in place, an import maps cleanly onto them instead of creating its own. See the warning below about why that matters.
Employee imports and HRMS syncs create org values that do not already exist. A bulk upload or a connected HRMS that carries a business unit, department, designation, grade, cost center, or location Empuls has not seen before will silently create it rather than reject the row.Matching against existing values ignores letter case and surrounding spaces, so sales, Sales, and Sales all resolve to the same existing value. Anything else does not — Sales, Sale, and Sales Dept become three separate business units, each with its own employee count, each appearing separately in every filter dropdown.This is the single most common way an org structure degrades. Create your canonical values first, then check the import file against them.

​
Creating and editing values

Business units, departments, designations, grades, and cost centers behave identically. Each has a name field and, for business units only, an optional head. Locations and the company details tab have their own rules, covered below.

​
Field rules

Departments, designations, grades, and cost centers have only a name field. There is no head field on them — see Head fields live on the employee, not the entity.
Country, state, and city searches match your text anywhere in the name, not just at the start — searching ind finds both India and Indonesia.

​
Where a value can be created from

Business units, departments, designations, grades, and cost centers can each be created from four places:
  1. Its own tab on this screen.
  2. The single-employee create or edit form, if the value you need does not exist yet.
  3. A bulk employee upload.
  4. A connected HRMS sync.
Locations can be created from the first two only — the location tab and the single-employee form. Editing and deleting, however, can only be done here. Neither the employee screens nor an HRMS sync can rename or remove an org value — they can only add new ones and map people to them. Lists show 10 rows by default, with 10, 15, and 100 as the page-size options.

​
The employee count tells you who is attached

Every row on these tabs shows an employee count — the number of people currently mapped to that value. It is a hyperlink, and it is the single most useful control on the screen. Clicking it takes you to the employee list with that value’s filter already applied, and the active, invited, and disabled counts recalculated for just those people. Use it to answer “who exactly is attached to this?” before you touch anything. A newly created value always shows a count of 0. The count only rises when employees are mapped to it — through a single employee edit, a bulk upload, or an HRMS sync. You cannot map people from this screen.
Bulk reassignment — moving every employee from one value to another — is only possible as part of deleting the value they are on. There is no standalone bulk-move. This is worth knowing before you plan a reorganisation.

​
The mapped-to panel tells you what depends on it

This is the most useful thing on the screen and the least obvious, because it only appears once you start a deletion. The employee count tells you which people are attached to a value; this panel tells you which configurations are. When you begin deleting a business unit, department, designation, grade, cost center, or location, the confirmation shows a mapped-to panel listing every configuration that references the value you are about to remove, grouped into four categories: Each entry is a link that takes you straight to that group, budget, gift, or award, so you can see the condition before you destroy it. Long lists are truncated with an option to see the rest.
Read this panel before you confirm any deletion. It is the only place in Empuls that tells you which configurations depend on an org value, and the answer is frequently more than the person deleting expects.If the panel lists things you did not know about, cancel, fix those configurations first, and come back.
Note what the panel does not cover: report filters, saved report views, and survey audience conditions are not listed. Deleting a value still affects those, so check them separately if you rely on them.

​
Editing a value people are mapped to

The behaviour depends on the employee count.
  • Count is 0. You go straight to the edit form, pre-filled with the current values. Nothing else is affected.
  • Count is above 0. You get a confirmation first, telling you how many employees’ records will be updated. Proceeding opens the form; submitting updates both the value itself and the stored value on every mapped employee.
Renaming does not move anyone. The employee count stays the same, and everyone stays mapped.
Renaming propagates the new name into downstream filter dropdowns and into conditions already configured — so an existing budget rule or award condition follows the rename rather than breaking.What it does not update is anything outside Empuls that matches on the old name. An HRMS sync still sending the old spelling will create the old name again as a new value on its next run, leaving you with both. Rename in your HRMS at the same time.

​
Deleting a value

Deletion is where the real damage happens, so Empuls makes you confront the impact first.
  • Count is 0. A simple confirmation, then it is gone.
  • Count is above 0. You get a page showing how many employees are affected, and you must choose one of two outcomes:
Clear the value on everyone. Every mapped employee has that field emptied. The value disappears from the list. This is the default option, and it is the destructive one. Reassign everyone to another value. You pick a replacement from a searchable list of the remaining values. Every mapped employee moves to it, the old value is removed, and the replacement’s employee count rises by the number of people migrated. You cannot confirm without selecting a replacement.
Clearing the value silently deactivates every downstream condition that referenced it. Specifically:
  • Groups — auto-membership conditions on that value stop matching, so those employees are no longer added.
  • Automated budget allocation — rules referencing it stop delivering budget to those employees.
  • Gifts — manual, scheduled, and automated gift conditions referencing it stop resolving, so those employees stop receiving under that condition.
  • Awards — every role condition referencing it goes inactive for those employees, across approver, nominator, nominee or receiver, moderator, and jury roles.
Existing configurations keep showing the deleted name, but the condition no longer matches anyone. Nothing errors and nothing warns you — the automation simply stops delivering. This is a genuinely difficult failure to diagnose after the fact, because the rule still looks correctly configured.Reassigning instead of clearing has the mirror-image effect worth anticipating: if the replacement value is already referenced in budget, gift, or award conditions, the migrated employees immediately start qualifying under them. People can begin receiving budget or gifts they were not receiving the day before.Before deleting anything, click its employee count to see exactly who is attached, and check whether the value appears in any budget, gift, group, or award condition.
Filter dropdowns for new groups, gifts, and awards only offer currently active values, so a deleted value cannot be selected again — but it stays visible inside configurations that already reference it.

​
Locations have an extra step: the country mapping

Locations follow the same create, edit, and delete rules as the other five values, including the two-option delete. They have one thing the others do not — a country, state, and city mapping. Rows without a country show an inline action to add one; rows with a country show an edit action to change it. Either way you get a country search, and before the change applies you have to tick an acknowledgement that it will update the stored location metadata on every employee mapped to that location. Country, state, and city cascade: the state list comes from the chosen country and the city list from the chosen state. Country suggestions show the country name, its dialling prefix, and its ISO code, and the search matches your text anywhere in the name.
Map every location to a country. The country is optional in the form but the multi-wallet and redemption modules depend on it. Employees at a location with no country mapping will not get correct wallet and redemption behaviour.If redemption is misbehaving for one office and working everywhere else, check that location’s country mapping first.
See Redemption wallets for how location feeds wallet criteria.

​
Head fields live on the employee, not the entity

This trips people up, so it is worth being explicit. The only head field on an org entity is the business unit head. Departments, designations, grades, and cost centers have a name and nothing else. The other head relationships — HR representative, department head, and cost center head — are fields on the employee record, set per person rather than per department. You set them through the single-employee form, a bulk upload, or an HRMS sync, using these columns: Each must resolve to a real Empuls user — either someone who already exists, or someone being created in the same import file. An address that resolves to nobody fails the row with an invalid-email error rather than being ignored. These fields matter because they are where HRMS connectors map their own head fields. Connectors declare a mapping from their field names to Empuls’s, so a Darwinbox sync maps its HRBP email onto hr_email and its head-of-department email onto department_head_email. Some connectors derive the department head by looking it up from the department name — which means the department name in Empuls has to match the department name in the HRMS, case-insensitively, or the head email resolves to nothing. Head fields also drive real behaviour: they are the transfer targets when an employee exits with pending nominations to approve, and they scope role-based report access.

​
Troubleshooting

An import or HRMS sync created them. Matching against existing values ignores case and surrounding whitespace but nothing else, so any difference in spelling, abbreviation, or punctuation creates a new value.To consolidate: delete the duplicate and choose to reassign its employees to the value you want to keep. That moves everyone in one step and removes the duplicate. Then fix the source — the import file or the HRMS field — or the duplicate comes back on the next sync.Check the employee count on each duplicate first. Some carry people and some carry none.
Check whether the org value the condition references still exists and still has those people mapped to it.Two things produce this symptom. Someone deleted the value and chose to clear it on all employees — the condition still shows the old name but matches nobody. Or an import moved those employees onto a differently spelled duplicate, so they no longer match the value the rule points at.Open the value’s employee count from this screen to see who is actually mapped, then compare that against who the rule is meant to cover.
The import ran but the value did not resolve. Check the column heading in your file matches what the import expects, and check the value itself is not empty in the source row.If the value was present, look for it in the relevant tab — if the import created it as a new value, the employee is mapped to that new one rather than to the value you expected.
Yes, both. Locations behave like the other five values: renaming updates the stored value on every mapped employee, and deleting gives you the same choice between clearing the field on everyone and reassigning them to another location.Editing a location that has employees mapped to it asks you to confirm first; editing one with nobody mapped goes straight to the form. Renaming does not change the country mapping, so you do not need to re-set it.
Check that location’s country mapping. The country is optional when you create a location, and without it the multi-wallet and redemption modules do not resolve correctly for employees mapped there.Add or correct the country from the location row. You will have to acknowledge that it updates the stored metadata on every employee at that location.
No. The permission is all-or-nothing: granting it gives full create, edit, and delete across all seven tabs. There is no read-only level and no per-tab granularity.If someone only needs to see the values, consider whether a report filter or the employee list gives them what they need instead.
Deletion removes the value from the list and from the dropdowns used when creating something new, but it does not rewrite configurations that already reference it. Those keep displaying the old name while matching nobody.Edit the condition to point at a live value, or delete the condition.

Manage employees

Mapping employees to org values, single edits, and bulk uploads.

Access control

Granting the business information permission to other roles.

Automated budgets

Budget rules that target employees by org value.

Redemption wallets

Wallet criteria, including location-based eligibility.

Custom reports

Report filters and role-based report scoping.

Introduction to awards

Award eligibility and role conditions.