Letter Builder

Why employee data quality matters so much

In Letter Builder, employee records are not only directory entries. They are a major source of merged data. If titles, departments, company assignments, or identifiers are wrong, letters will be wrong too.

What the employee record covers

• Profile picture
• Employee ID and full name
• Email and password at creation time
• Gender, job title, and department
• Role, employment type, company, and supervisor
• Contract start date
• Basic salary and transportation allowance

User translations: what they are and why they exist

A user translation lets you store localized versions of employee-specific fields such as name, gender, job position, department, contract date, company label, and employment type. This matters when a template is authored in multiple languages and the employee data itself should also be presented in a language-aware form.

How translation management works now

• Create translations from the user view page
• Create translations from the user edit page
• Create translations from the translations relation manager
• Edit translations directly inside the relation manager
• Filter available translation languages so duplicates are prevented early
• Keep uniqueness validation as a backup so one user cannot have the same language twice

Why duplicate-language blocking matters

If a user could have multiple translations for the same language, the system would have no clean answer to the question, "Which Amharic version should this letter use?" The uniqueness rule keeps translation behavior predictable.

Imports tied to users

• English employee import: creates or updates employees by id_number, auto-generates email and password defaults when needed, and resolves company data.
• Amharic translation import: attaches or updates the am translation for an existing employee using id_number.
• User export: the user list provides an export action so teams can review or back up people data.

User-data edge cases

• String vs relation values: some fields may exist in more than one shape historically, so avoid assuming every legacy record looks identical.
• Import company mismatch: normalize company naming before large imports to prevent duplicate company records.
• Translation import without base user: the Amharic importer intentionally skips rows when the base employee is missing.
• Salary and compensation data: these may be sensitive, so decide carefully who should manage and review them.

Best practices for employee master data

• Choose one authoritative format for job titles and departments.
• Keep employee IDs stable and unique because imports depend on them.
• Review user translations whenever a role or department changes in the base record.
• Treat company assignment changes carefully because they affect template eligibility.

Translation governance advice

If your organization supports several languages, decide early who is responsible for user translations. Without ownership, localized job titles and departments tend to drift, which makes output inconsistent even when the templates themselves are correct.