This article covers the bulk import of departments from a file, one-time or on a scheduled basis. The main Data Imports - An Overview article should also be reviewed for information on importing data to Absorb in general.
Departments are the primary way that users are categorised in Absorb. Each user must belong to a single department. Departments can also be nested within each other by assigning parent departments, creating a hierarchy tree. More information on general department setup can be found in our Department & Groups Setup article. For the purposes of this article, we'll assume that you are already familiar with setting departments up manually in Absorb through the admin portal.
There are quite a few options available for processing departments, but here are the minimum pieces of input that we'll need from you in order to set things up:
Preparing the File
Ensure you've downloaded the most recent Absorb Data Mapping document from this helpdesk article. Refer to the Users tab for a list of fields that can be included, including the minimum required fields and any dependencies. Once your file is created, please take a moment to validate the content by considering the items noted here.
In addition to the generic configuration options available to all modules, the following configuration options are available for Users (mandatory marked with *):
The Data Imports - Configuration article covers column mapping in general. You will need to specify which Absorb fields should be mapped to each column in the file based on column headers (e.g. The column with header "EID" should be mapped to the Absorb "External ID" field). The following fields/columns are mandatory for Departments:
- ExternalID (Only if used as Unique Identifier, which is STRONGLY recommended)
This property will be used to uniquely identify the record for the purposes of updating existing records (i.e. the key). Options available:
- External ID (recommended)
Note: Absorb does not enforce uniqueness on either of these fields. The Name field is displayed in various reports, so it's harder to maintain uniqueness. The External ID can be used to store a less human-readable value like a numerical or alphanumeric ID.
Fallback Parent Department
Specifies the department to be used as the parent when the parent defined in the import file is missing or invalid. Keep your admin permissions in mind here; it's sometimes safest to fall back to a parent department near the bottom of your hierarchy to avoid inadvertently granting admin permissions over a large portion of your department tree. Options available:
- Specific department external ID
- Specific department name (must be unique)
- Top Level Department
Note: A typical department file will have a single department record with no parent defined, whose unique identifier matches the existing very top level department in Absorb. Each Absorb portal comes preloaded with a single top level department, but you may need to manually edit its External ID or Name to match the record in your file. When the integration runs, it will match to the existing top level department.
Another option is to omit that top level department from your file, and only provide records with parents. This (safely) assumes that the very top level department already exists, though you would still need to manually edit its External ID or Name in Absorb so it can be used as the parent for other departments in your file.
If you provide additional records with no parent, whose unique identifier does not match the existing top level department, they will be assigned the Fallback Parent Department.
The following list of objects are often imported alongside Departments:
Name,ExternalId,Parent_ExternalId Demo Organization,00001, Sales,00002,00001 Support,00003,00001 Human Resources,00004,00001 North America Sales,00005,00002 European Sales,00006,00002