Documentation menu

Getting Started

Welcome to Performance BlocksKey conceptsRoles and accessQuick tour: your first 15 minutes

For Employees

Your dashboardConversations with your managerViewing your summariesGiving 360 feedbackTracking your objectives

For Managers

The manager dashboardCreating observationsRunning 1:1s and conversationsWriting performance summariesTeam summariesManaging objectivesAttributes and skillsRunning 360 feedback cycles

For Admins

The admin console at a glanceManaging employeesOrganization settingsDepartments and the org chartBuilding the attributes libraryCustom fieldsRunning review cyclesContent flagging and moderationAudit logsBilling and subscription

Henry Agent

Meet HenryUsing the Henry panelGuided flowsKnowledge base and retrievalHenry analytics

Integrations

Integrations overviewSlack integrationMicrosoft Teams integrationChrome extensionEmail captureHRIS sync

Security and IT

Security overviewSetting up single sign-on (SSO)Passwords and two-factor authenticationData and privacyNotifications and channels

Developers

API overviewAuthentication and API keysObservations APISummaries APIEmployees APIObjectives APIWebhooksRate limits and errors

Reference

Plans and pricingFeature availability matrixGlossaryKeyboard shortcutsFrequently asked questions

For Admins

Custom fields

Add custom employee metadata fields, control visibility, and map them from HRIS. Useful for cost center, location, employee type, and similar.

Who can use this: Org admins only.

Custom fields are how you add organization-specific metadata to employee records. The built-in fields (name, email, department, manager, roles) cover the basics; custom fields cover everything else — location, employee type, hire cohort, badge number, internal HR system ID. Once defined, custom fields show up on employee profiles, in filters, in CSV imports/exports, and in HRIS field mappings.

This article covers field types, visibility, mapping from HRIS, and common use cases.

When to use a custom field

Use a custom field when:

  • You need the same piece of information on every (or most) employee records.
  • That information is not already covered by a built-in field.
  • You want to filter, sort, or report by that information.

Use something else when:

  • The data is sparse (3 employees out of 500). A note in the employee profile is fine.
  • The data is performance-related (skills, ratings, behaviors). Use attributes instead — see Building the attributes library.
  • The data is sensitive (compensation, health information, race/ethnicity in jurisdictions where you should not store it). Performance Blocks is not a system of record for sensitive HR data; keep that in your HRIS.

Field types

Custom fields support these types:

Type When to use
Text Free-form short strings — IDs, badge numbers, codes
Long text Multi-line notes
Number Integer or decimal values
Date ISO 8601 date (no time component)
Single-select Pick one from a defined list
Multi-select Pick zero or more from a defined list
Boolean Yes/no checkbox
Email Validated email format
URL Validated URL format

Pick the most constrained type that fits. Single-select is almost always better than free-form text when the value comes from a known set — it prevents typos, enables filtering, and makes reporting reliable.

Creating a custom field

  1. Open Admin → Settings → Custom Fields.
  2. Click Add field.
  3. Fill in:
    • Label — what users see (e.g. "Employee Type").
    • Internal name — auto-generated from the label, used in CSV imports and the API. You can edit before saving; afterward it's locked.
    • Type — pick from the table above.
    • Description — shown as helper text on the field.
    • Required — whether the field is required when adding/editing employees.
    • Options (for select types) — the list of allowed values. Add as many as needed.
    • Default value (optional) — pre-populated for new employees.
  4. Configure visibility (covered below).
  5. Save.

The field appears immediately on every employee record. Existing records have empty (or default) values until populated.

Internal name conventions

Internal names use snake_case. Performance Blocks normalizes spaces to underscores and lowercases. "Employee Type" becomes employee_type. Keep them short — they appear in CSV column headers and API responses.

Once a field is created, the internal name cannot be changed (it would break CSV imports, integrations, and any API consumers). The label can change freely.

Visibility per role

Each custom field has visibility settings per role:

  • Org admin — always sees and can edit (cannot be restricted).
  • Manager — choose: hidden, view-only, view-and-edit (for own reports).
  • Employee (self) — choose: hidden, view-only, view-and-edit (on their own record).
  • Employee (others) — usually hidden; can be set to view-only for org-wide visible fields like office location.

Use visibility deliberately:

  • Sensitive operational data (badge number, internal HR ID): admin only.
  • Reference info (office location, employee type): visible to all, editable by admin.
  • Self-service info (preferred name spelling, dietary preference): editable by self.

Visibility is enforced at the API level, not just in the UI. A hidden field is genuinely hidden — it does not appear in API responses for the role.

Where custom fields show up

Once defined and populated, custom fields appear in:

  • Employee profile — under a "Custom" section, ordered as in Settings.
  • Employee selectors — name, email, and selected custom fields can be included in the secondary text. Configure under Settings → Custom Fields → Display.
  • Filters — the Employees page, the org chart, the audit log, and review cycles all support filtering by select-type custom fields.
  • CSV import/export — column header matches the field's internal name.
  • HRIS field mapping — see below.
  • API — fields are available in the employee resource (Agentic plan).

HRIS field mapping

When HRIS sync is enabled (Agentic plan), you can map HRIS fields to Performance Blocks custom fields. This pulls structured metadata from your HRIS into Performance Blocks automatically.

To configure:

  1. Open Settings → Integrations → HRIS → Field Mapping.
  2. For each Performance Blocks custom field, choose:
    • Map from HRIS — pick the source field. Sync overwrites Performance Blocks values.
    • Don't sync — Performance Blocks owns the field; HRIS is ignored for it.
  3. Save.

Mapped fields become read-only in Performance Blocks (the lock icon appears next to them on employee profiles). Unmapped fields remain editable.

Common HRIS-mapped fields:

  • Cost center / business unit (single-select).
  • Office location (single-select).
  • Employee type — full-time, part-time, contractor (single-select).
  • Hire date (date).
  • Tenure-related dates like "promotion date" (date).

Field types must be compatible. You can map an HRIS string field to a text field; you cannot map a free-form HRIS string to a Performance Blocks single-select unless every value matches an option.

Use cases

Patterns that come up repeatedly:

Cost center

Type: Single-select. Visibility: admin and manager (view-only). Source: HRIS. Use to filter Team Summaries by cost center for finance reporting.

Office location

Type: Single-select. Visibility: all roles (view-only for non-admins). Use to scope review cycles to specific offices, or to filter the org chart by location.

Employee type

Type: Single-select with options like Full-time, Part-time, Contractor, Intern. Visibility: admin and manager. Use to scope review cycles to specific types (interns may be on a different cadence).

Hire cohort

Type: Single-select. Visibility: admin only. Useful for "started in 2023 H1" cohort analysis. Often computed from hire date but stored as its own field for filter convenience.

Badge number / internal ID

Type: Text. Visibility: admin only. Use as a join key with external systems.

Pronouns

Type: Single-select with options like she/her, he/him, they/them, other. Visibility: editable by self, view-only for everyone else. Most orgs make this optional and self-managed; a small percentage make it required.

CSV imports and custom fields

Custom fields integrate with CSV import described in Managing employees. The column header must match the field's internal name. Values must parse as the field's type:

  • Date fields: YYYY-MM-DD.
  • Boolean fields: true or false.
  • Single-select: must match an option exactly (case-sensitive).
  • Multi-select: comma-separated; each value must match an option.
  • Number: standard decimal notation.

Validation errors during import name the row and the field. Fix and re-upload.

Editing and archiving fields

To edit a field:

  1. Open it from the list.
  2. Change label, description, options, defaults, or visibility.
  3. Save.

You cannot change the field type after creation. To switch types, archive the old field and create a new one.

To archive:

  1. Open the field.
  2. Click Archive.
  3. Confirm.

Archived fields:

  • Stop appearing on employee profiles for new viewing.
  • Remain in the data layer — historical CSV exports and API queries that include them still return values.
  • Can be unarchived.

Archive is reversible. Hard deletion of a field that has values requires a support request and is irreversible — values are wiped.

Performance and limits

You can have up to 50 custom fields per organization. In practice most orgs use 5 to 15. If you find yourself approaching the limit, audit — most "we need another field" requests turn out to be solvable with grouping or with attributes.

Select-type fields support up to 100 options. If you're approaching that, the field probably belongs as a free-form text or as something more structured (a department, a separate entity).

Frequently asked

Can custom fields be required for some employee types and optional for others? No — required is a per-field setting. To approximate, leave the field optional and use reporting to surface unfilled records for the cohort that should have it.

Can I create a field that derives from another (e.g., cohort from hire date)? Not natively. Compute it externally and set it via CSV import, or via the API.

Can I have a field visible only to a specific subset of admins? Not currently. Visibility is per-role. For sensitive fields you want to hide from some admins, store the data outside Performance Blocks.

Why doesn't the field appear in the audit log filter? Only select-type fields are filterable. Free-form fields are searchable but not filterable.

Next steps

© 2026 Performance Blocks. All rights reserved.