> ## Documentation Index
> Fetch the complete documentation index at: https://help-empuls.xoxoday.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Business information and org structure
> Set up locations, business units, departments, designations, grades, and cost centers — the values that scope budgets, access control, award eligibility, wallet criteria, and every report filter in Empuls.
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 | What it holds |
| -------------------- | -------------------------------------------------------------------------------------------- |
| Business information | Company name, brand name, address, and your point of contact. The default tab when you land. |
| Locations | Your offices and work locations, each optionally mapped to a country. |
| Business units | The top grouping of employees. Optionally has a head. |
| Departments | Functional teams. |
| Designations | Job titles. |
| Grades | Pay or job grades. |
| Cost centers | Financial cost center codes. |
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.
| Where they are used | What they do there |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Groups** | Auto-membership conditions. A group set to "everyone in the Sales business unit" resolves against the business unit on each employee's record. |
| **Automated budget allocation** | Which employees a budget rule funds. Budget and wallet criteria are stored against the org value's internal ID, not its name. |
| **Redemption wallets** | Wallet eligibility criteria, including location-based rules. A location without a country mapping breaks this — see [Locations have an extra step: the country mapping](#locations-have-an-extra-step-the-country-mapping). |
| **Gifts** | Recipient conditions on manual gifts, scheduled gifts, and gift automation. |
| **All award programs** | Eligibility conditions on every award type — spot, nomination, jury, and incentive. |
| **Award role conditions** | Who can act in each role on an award: approver, nominator, nominee or receiver, moderator, and jury. |
| **Reports** | Filters on every report, and the scoping for role-based report access. An HRBP sees their business unit; a cost center head sees their cost center. |
| **Survey audiences** | Metadata conditions that decide who receives a survey. |
| **Employee exit** | Where pending nominations get transferred — reporting manager, HRBP, department head, business unit head, or cost center head. |
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](/admin/user-management/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.
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.
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.
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.
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.
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
| Field | Required | Limit | Rules |
| ---------------------------------------- | -------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Name | Yes | 250 characters | Alphanumeric. Leading and trailing whitespace is rejected. |
| Business unit head (business units only) | No | — | A searchable list of active and invited users' email addresses. You can also paste a valid email directly. Blank if not set. |
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](#head-fields-live-on-the-employee-not-the-entity).
| Field | Required | Limit | Rules |
| ----------------- | ---------------------------- | -------------- | ------------------------------------------------------------------------------------------ |
| Location name | Yes | 250 characters | Alphanumeric. Cannot be blank or whitespace-only, and is stored trimmed. |
| Street address | No | 100 characters | Alphanumeric. Leading and trailing whitespace is rejected. |
| Country | No, but strongly recommended | — | Searchable. Each suggestion shows the country name, its dialling prefix, and its ISO code. |
| State or province | No | — | Populated from the selected country. |
| City | No | — | Populated from the selected state or province. |
| Field | Required | Limit | Rules |
| ------------------------------- | -------- | -------------- | --------------------------------------------------------------------------------------- |
| Company name | Yes | — | Pre-filled from your company setup, and editable. |
| Company brand name | No | — | If you enter something it cannot be blank or whitespace-only after trimming. |
| Address | Yes | 250 characters | Alphanumeric. Not pre-filled — you have to enter it. |
| Zip code | Yes | — | |
| Country | Yes | — | Searchable. Changing it clears the state and city. |
| State or province | Yes | — | Populated from the selected country. Changing it clears the city. |
| City | No | — | Populated from the selected state or province. |
| Point of contact name | Yes | 50 characters | Alphanumeric, no leading or trailing whitespace. Pre-filled from company creation. |
| Point of contact email | Yes | — | Must be a valid email address. Pre-filled from company creation. |
| Point of contact contact number | Yes | — | Required whenever you save any change on this tab, not only when you change this field. |
Changes on this tab save only when you submit. There is no auto-save, and any unfilled mandatory field is flagged inline.
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:
| Category | What it lists |
| -------- | -------------------------------------------------------------------- |
| Groups | Groups whose auto-membership conditions reference this value. |
| Budgets | Budget rules whose allocation criteria reference it. |
| Gifts | Manual, scheduled, and automated gift configurations that target it. |
| Awards | Award programs whose eligibility or role conditions reference it. |
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](/admin/finance/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:
| Employee field | What it holds |
| ------------------------ | ----------------------------------------- |
| `manager_email` | The employee's reporting manager. |
| `hr_email` | The employee's HR representative or HRBP. |
| `department_head_email` | The head of this employee's department. |
| `cost_center_head_email` | The head of this employee's cost center. |
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.
## Related pages
Mapping employees to org values, single edits, and bulk uploads.
Granting the business information permission to other roles.
Budget rules that target employees by org value.
Wallet criteria, including location-based eligibility.
Report filters and role-based report scoping.
Award eligibility and role conditions.