> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firstwork.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Core Concepts

> Atomic business concepts that define the Firstwork platform vocabulary.

Before diving into specific features, understand the core entities and concepts that power Firstwork. For field-level attributes and relationships, see the [Data Model](/knowledge-base/data-objects).

## Company

A **Company** is the top-level tenant in Firstwork. Users, hiring flows, automations, integrations, and data all belong to a company and run in that company's isolated workspace.

Company profile, branding, timezone, and language settings are configured in [Company Details](/knowledge-base/settings/company-details). For the object attributes that make up a company, see the [Company entry in the Data Model](/knowledge-base/data-objects#company).

## User

A **User** represents an individual person in the system. Users authenticate through the supported login methods and can relate to one or more companies through contracts.

Use [Roles and Access](/knowledge-base/roles-and-access) for portal roles and permissions, and the [User entry in the Data Model](/knowledge-base/data-objects#user) for user attributes.

## Contract

A **Contract** represents the relationship between a User and a Company. It is the worker or admin record that tracks status, legal entity assignment, onboarding context, and access permissions.

> \[!NOTE]
> A user can have multiple contracts, including historical contracts with the same company or active contracts with different companies.

For contract fields, statuses, creation paths, and ACL behavior, see [Contracts](/features/contracts) and the [Contract entry in the Data Model](/knowledge-base/data-objects#contract).

## Hiring Flow

A **Hiring Flow** defines the stages a candidate goes through during the recruitment process. It combines form pages, stages, decision rules, visibility rules, automations, and funnels into a public application workflow.

Start with [Pages](/knowledge-base/hiring-flows/pages), [Stages](/knowledge-base/hiring-flows/stages), and [Funnels](/knowledge-base/hiring-flows/funnels) for the operational setup.

## Application

An **Application** tracks a specific candidate's progress through a Hiring Flow. It records the current stage, submitted form data, compliance status, and transition history.

For day-to-day application management, see [List Applications](/knowledge-base/hiring-flows/applications/list-applications) and [View and Edit Applications](/knowledge-base/hiring-flows/applications/view-edit). For object attributes, see the [Application entry in the Data Model](/knowledge-base/data-objects#application).

## Form

A **Form** is the configurable data collection structure behind hiring flows, onboarding flows, courses, templates, and integration steps. Forms are made from pages and form elements, and submissions store the collected answers.

Use [Pages](/knowledge-base/hiring-flows/pages) for form structure, the [Question Types](/knowledge-base/hiring-flows/question-types/text) section for supported field types, and the [Form Entities section](/knowledge-base/data-objects) for the underlying objects.

## Compliance Rule

A **Rule** defines conditional logic that evaluates platform data. Rules power navigation, assignment, recollection, automation filters, and other decision points.

Use [Navigation Rules](/knowledge-base/hiring-flows/decision-rules) for hiring-flow rule behavior. Rules can compare static values, other fields, or [Object Graph](/knowledge-base/object-graph) paths.

## Automation

An **Automation** is an event-driven workflow that runs actions in response to a trigger. Automations can send messages, update records, call integrations, create contracts, request recollection, and chain other workflows.

For implementation details, start with [Building Flows](/knowledge-base/automations/building-flows), then use the [Triggers](/knowledge-base/automations/triggers) and [Actions](/knowledge-base/automations/actions) references. Runtime execution and concurrency behavior are covered in [Workflow Mapping](/knowledge-base/workflow-mapping#2-automation-execution).

## Recollection

**Recollection** is the process for asking a candidate, applicant, worker, or contract holder to re-submit specific fields after data has already been collected.

**How it works:**

1. An admin, automation, or template selects the fields to recollect and the reason for each field.
2. Firstwork marks the latest matching form element submissions as pending recollection, stores the reason, and can optionally hide the previous value by clearing it for recollection.
3. The recipient gets a recollection link by email or SMS. The link opens only the pending recollection fields rather than the full flow.
4. The recipient submits the requested values. Firstwork validates that the payload matches currently pending recollection fields and updates the relevant submissions.
5. Firstwork clears recollection flags for completed fields, updates the application or contract recollection status, and writes activity logs for requested, completed, partially completed, or cleared recollection.
6. Recollection completion can trigger automations through `RECOLLECTION` triggers or through post-recollection automations configured on a `Recollect Data` action.

**Key concepts:**

* **Recollection Config** — Company, hiring-flow, or onboarding-flow settings for recollection behavior
* **Recollection Reminders** — Idle-day reminders for incomplete recollection requests
* **Recollection Template** — A reusable set of fields, reasons, notification templates, submission requirements, and clear-value settings
* **Recollection Trigger** — An automation trigger that listens for recollection completion for selected form elements
* **Recollection Status** — Applications and contracts move through `NOT_REQUESTED`, `REQUESTED`, and `COMPLETED`
* **Recollect Data Action** — Sends a recollection request, can clear existing values, and can define automations to run after recollection
* **Partial Completion** — A recollection can complete only the fields that passed validation while leaving other requested fields pending
* **Linked Applications** — Recollection can include child hiring-flow applications and foreign-key-linked applications for the same user

### Dynamic Data Recollection

**Dynamic Data Recollection** marks fields for correction based on validation output instead of sending a fixed recollection request for a predefined list of fields.

It is useful when Firstwork detects invalid, missing, or inconsistent data while processing a form. The system stores validation errors on the affected field submissions, and the candidate or worker can correct those fields when they next load the flow.

### Self-Serve

**Self-Serve** lets applicants update eligible fields after their original submission without requiring an admin-triggered recollection request.

Self-serve fields are controlled at the form element level. When an applicant updates data through self-serve, Firstwork can emit recollection-style automation events with a `SELF_SERVE` source so downstream automations can respond separately from standard recollection.

## Dynamic Variables

Firstwork's dynamic variable system lets templates, messages, webhook payloads, and automation fields insert runtime values with `{{...}}` placeholders.

Use [Dynamic Variables](/knowledge-base/dynamic-variables) for placeholder syntax and template behavior. Use the [Object Graph](/knowledge-base/object-graph) when a placeholder needs to reference platform data by path.

## Access Control

Firstwork uses access controls to govern what each person can view or change. Contract ACLs control data permissions inside a company, while portal roles define whether someone operates as an admin, applicant, worker, or platform staff user.

See [Contracts](/features/contracts#access-control) for contract ACL behavior and [Roles and Access](/knowledge-base/roles-and-access) for portal roles and scoping.

## Legal Entity

A **Legal Entity** represents a subsidiary, division, or regional office within a Company. Legal entities allow organizations to manage different compliance requirements, contracts, and work locations under one company umbrella.

Legal entities are attached to company configuration and contracts. See [Contracts](/features/contracts) for how they affect worker records and [Company Details](/knowledge-base/settings/company-details) for related company setup.