LB

Documentation

Letter Builder

Browse documentation pages
Theme aware

Getting Started

Overview Quick Start

Core Features

Admin Panel Employee Panel Companies Letter Templates Template Studio Letter Requests Generated Letters Printing & Output Users & Translations

Configuration

Settings Placeholders & Merge Tags Languages & Localization

Data

Import & Export Revisions & Audits

Reference

Examples FAQ
Data Data

Import & Export

Data import formats, sample files, and export behavior.

Readable guides Practical edge cases Feature-by-feature navigation
Start here
First-run setup and happy path
 Common issues
Fast answers for operators

Why imports matter here

Letter systems become valuable only when employee data exists at scale. Manual entry is useful for testing and exceptions, but imports are what make the product practical for real teams.

Built-in import flows

  • English employee import: maps employee identity and HR data into the main user record.
  • Amharic translation import: maps localized employee values into the user's am translation record.

What the English importer does behind the scenes

  • Uses id_number as the primary identity key.
  • Creates or updates the employee record if that ID already exists.
  • Generates a fallback email when one is not provided.
  • Generates a random password for imported users.
  • Creates or fetches the company based on the imported company name.
  • Attempts to parse the contract start date from m/d/Y.

What the Amharic importer does behind the scenes

  • Looks up the base employee by id_number.
  • Skips translation creation if the base employee does not exist.
  • Updates or creates the am translation instead of creating a second employee.
  • Also attempts to parse the contract start date from m/d/Y.

Download sample files

Expected columns

English import
id_number,name,email,gender,job_position,department,company,contract_starting_date,basic_salary,transportation_allowance,employment_type

Amharic translation import
id_number,name,gender,job_position,department,contract_starting_date,employment_type

Import edge cases

  • Date format mismatch: if your sheet does not use m/d/Y, contract dates may not parse correctly.
  • Company-name inconsistency: importing Droga Tech and Droga Technology may create separate company assumptions.
  • Translation-before-user: Amharic translation import depends on the employee already existing.
  • Column naming drift: use the sample files to avoid mapping errors.

Recommended import sequence

  1. Confirm company naming standards.
  2. Import base employees first.
  3. Review a sample of imported users in the admin UI.
  4. Import language-specific translations second.
  5. Test one request and print flow using an imported user.

Why imports should be validated with live workflows

An import can appear successful while still producing poor letters if company names, departments, titles, or dates were normalized incorrectly. The most trustworthy import validation is not the success count alone, but whether an imported employee can move through request, approval, and print correctly.