Contains additional compensations configured in employee contracts. This table stores fixed additional payments or benefits assigned to employees as part of their contract configuration.

Entity

Compensation / Contracts / Employees

Use Cases

• Total compensation analysis
• Employee compensation structure analysis
• Labor cost prediction
• Identification of compensation patterns

Keys

Relationships

• additional_compensations.contract_id → contracts.id
• additional_compensations.employee_id → employees.id

Key Fields

Features

• amount → additional compensation value
• type → compensation category analysis
• recurrence → payment frequency patterns
• contract_id → compensation analysis by contract
• employee_id → employee compensation history

Contains all candidate applications for job postings published through ATS. Stores candidate information, application source, qualification status, and current stage within the recruitment process.

Entity

Recruitment / Candidates / Applications

Use Cases

• Recruitment source effectiveness analysis
• Candidate progression prediction
• Hiring funnel analysis
• Identification of recruitment patterns

Keys

Relationships

• ats_applications.ats_job_posting_id → ats_job_postings.id
• ats_applications.employee_id → employees.id

Key Fields

Features

• source → candidate source performance analysis
• medium → recruitment channel effectiveness
• qualified → candidate evaluation outcome
• phase → recruitment funnel progression
• created_at → application volume and recruitment trends over time
• ats_job_posting_id → candidate behavior analysis by job posting

Contains all job postings created and published through ATS. Stores position information, publication status, remote configuration, creation date, department, and associated office.

Entity

Recruitment / Job Postings / Positions

Use Cases

• Job posting performance analysis
• Hiring demand prediction
• Recruitment channel analysis by position
• Identification of hiring trends

Keys

Relationships

• ats_job_postings.id → ats_applications.ats_job_posting_id

Key Fields

Features

• status → job posting lifecycle analysis
• title → position classification and analysis
• remote → impact of remote positions on applications
• created_at → job opening trends over time
• department → hiring demand analysis by area
• office → recruitment patterns by location

Contains company holidays and non-working days configured in the platform. Stores holiday information, whether it applies as a half-day, the effective date, and optional employee assignment when the holiday is specific to an employee.

Entity

Time Management / Holidays / Employees / Attendance

Use Cases

• Attendance and absence pattern analysis
• Workforce availability adjustment
• Non-working day impact prediction
• Productivity analysis considering working calendars
• Regional/company holiday trend analysis

Keys

Relationships

Common relationships:

• company_holidays.employee_id → employees.idPurpose: Identify holidays assigned to specific employees.
• employees.idPurpose: Analyze holidays by employee, team, office, country, or organizational structure.
• daily_time_configs.employee_id → employees.idPurpose: Compare holidays against employee schedules and adjust expected working hours.
• daily_time_configs.date → company_holidays.datePurpose: Identify days where employees should not have expected working hours.
• leaves.employee_id → employees.idPurpose: Differentiate employee-requested absences from company-configured non-working days.
• Attendance / timesheet-related tablesPurpose: Exclude holidays from attendance metrics, punctuality calculations, worked hours, and absence analysis.
• contracts.employee_id → employees.idPurpose: Analyze holiday impact based on contracts, employee groups, or workforce segments.

Key Fields

Features

• date → temporal analysis, seasonality, and productivity impact
• half_day → workforce availability adjustment
• summary → holiday type classification
• employee_id → employee availability patterns
• Holiday frequency → impact analysis on available working days and planning

Contains employee contract information. Stores data related to contract type, effective dates, employment conditions, working schedule, salary, professional category, and employment configuration.

It is one of the main tables for analyzing workforce structure, labor costs, employee lifecycle, and workforce management.

Entity

Employees / Contracts / Payroll / Workforce Management

Use Cases

• Workforce structure analysis
• Employee cost analysis
• Headcount management
• Hiring and termination analysis
• Workforce planning
• Contract condition tracking

Keys

Relationships

• contracts.employee_id → employees.idPurpose: Retrieve employee information associated with the contract.
• contracts.id → additional_compensations.contract_idPurpose: Relate fixed additional compensations configured within the employee contract.
• contracts.id → supplements.contract_idPurpose: Relate variable payments, bonuses, and additional compensation linked to the contract.
• contracts.employee_id → leaves.employee_idPurpose: Apply contractual conditions in absence-related calculations.
• contracts.employee_id → attendance / timesheet tablesPurpose: Compare contractual working hours against actual worked hours.
• contracts.employee_id → company_holidays.employee_idPurpose: Consider working calendars and employee availability.

Key Fields

Features / Relevant Data

• contract_type → employee segmentation by employment model
• starts_on / ends_on → employee lifecycle analysis
• salary_amount → labor cost analysis
• working_hours → workforce capacity analysis
• job_title → position classification
• professional_category → organizational structure analysis
• antiquity → employee tenure analysis
• termination_reason → turnover analysis
• current_contract → active contract identification
• additional_compensations → fixed additional compensation analysis
• supplements → variable compensation and additional payments analysis

Related cohort tables: contracts_cohort_by_day, contracts_cohort_by_month, and contracts_cohort_by_year provide historical snapshots of the same data at different time granularities, enabling point-in-time analysis without relying on the current contract state.

Daily snapshot of the contracts table. Stores contract information as it existed on each day, allowing historical analysis of contract changes over time.

Entity

Employees / Contracts / Historical Snapshots

Use Cases

• Daily headcount evolution
• Historical contract analysis
• Workforce changes over time
• Point-in-time reporting

Monthly snapshot of the contracts table. Stores contract information at a monthly granularity for historical workforce analysis.

Entity

Employees / Contracts / Historical Snapshots

Use Cases

• Monthly headcount analysis
• Workforce evolution
• Historical salary and contract reporting
• Monthly HR analytics

Yearly snapshot of the contracts table. Stores contract information at a yearly granularity for long-term historical analysis.

Entity

Employees / Contracts / Historical Snapshots

Use Cases

• Year-over-year workforce analysis
• Long-term contract evolution
• Annual HR reporting
• Historical compensation trends

Data related to the 9 box grid.

Contains information stored in Custom Tables created by each company. The structure of this table is dynamic and depends entirely on the custom fields configured by the client.

Initially, the table only contains employee_id. As new fields are added to a Custom Table, they will automatically appear as additional exposers in this dataset.

Entity

Employees / Custom Tables / Custom Fields

Use Cases

• Store custom employee information.
• Extend the data model without modifying standard tables.
• Build reports using company-specific data.
• Analyze business-specific attributes.

Keys

Relationships

• custom_tables_employees.employee_id → employees.idPurpose: Associate custom information with an employee.

Key Fields

Features / Relevant Data

• Allows completely custom employee attributes to be incorporated into the data model.
• The table structure varies from one company to another.
• Custom fields can be used for segmentation, reporting, or company-specific analysis.

Contains aggregated daily Time Tracking information. Unlike the shifts table, which stores transactional clock-in and clock-out records, this table provides pre-calculated daily metrics, making it the recommended dataset for reporting and time calculations.

Entity

Time Tracking / Attendance / Employees

Use Cases

• Time Tracking reports
• Worked hours calculations
• Planned vs. worked hours analysis
• Time balance calculations
• Productivity reporting
• Overtime calculations
• Attendance compliance reporting

Keys

Relationships

• daily_time_configs.employee_id → employees.idPurpose: Retrieve employee information.
• daily_time_configs.date → company_holidays.datePurpose: Identify company holidays and adjust expected working hours.
• daily_time_configs.employee_id → leaves.employee_idPurpose: Analyze absences together with worked hours.
• daily_time_configs.employee_id → contracts.employee_idPurpose: Compare contractual hours against worked hours.
• daily_time_configs.date → shifts.datePurpose: Retrieve transactional clock-in details when needed.

Key Fields

Features / Relevant Data

• estimated_hours → expected workforce capacity
• worked_hours → daily productivity analysis
• balance → deviation from expected working hours
• worked_hours_in_schedule → schedule compliance
• worked_hours_out_schedule → work performed outside scheduled hours
• tracked_hours → total recorded working time
• date → time-series and trend analysis

Contains all documents associated with employees within the platform. Stores information about uploaded files, document type, approval status, signature status, and relationships with other entities such as leaves and custom fields.

In addition to general employee documents, this table also includes documents uploaded as supporting evidence for employee leaves through the leave_id relationship.

Entity

Documents / Employees / Leaves

Use Cases

• Employee document management
• Signed and pending document tracking
• Leave supporting document validation
• Document auditing
• Compliance analysis

Keys

Relationships

• documents.employee_id → employees.idPurpose: Retrieve the employee who owns the document.
• documents.leave_id → leaves.idPurpose: Associate supporting documents with employee leave requests.
• documents.created_by → employees.id *(when applicable)*Purpose: Identify the user who created or uploaded the document.
• documents.custom_field_* → Custom FieldsPurpose: Store company-specific information configured through custom document fields.

Key Fields

Features / Relevant Data

• type → document classification
• approval_status → approval workflow analysis
• signature_status → signature compliance analysis
• created_at → document activity trends
• leave_id → leave supporting documentation analysis
• content_type → file format classification

Contains employee payroll cost center allocations. Stores the cost center assigned to each employee, including the cost center name, code, and the percentage of dedication allocated to each cost center.

This table is commonly used to distribute labor costs across multiple cost centers for payroll and financial reporting.

Entity

Payroll / Cost Centers / Employees

Use Cases

• Payroll cost allocation
• Cost center reporting
• Workforce cost analysis
• Financial and accounting reporting
• Employee dedication analysis across cost centers

Keys

Relationships

• employee_costs.employee_id → employees.idPurpose: Associate cost center allocations with employees.
• employee_costs.employee_id → contracts.employee_idPurpose: Analyze labor costs together with contractual information.
• employee_costs.employee_id → Payroll-related tablesPurpose: Allocate payroll expenses across different cost centers.

Key Fields

Features / Relevant Data

• cost_center_name → workforce distribution by cost center
• dedication → labor cost allocation analysis
• cost_center_code → financial reporting and accounting integration
• employee_id → employee cost distribution analysis

Contains the current presence status of employees within the platform. It indicates whether an employee is currently at work, on leave, or off work, providing a real-time overview of workforce availability.

Entity

Attendance / Presence / Employees

Use Cases

• Workforce availability monitoring
• Attendance dashboards
• Real-time employee presence reporting
• Operational workforce management
• Leave and attendance status analysis

Keys

Relationships

• employee_presences.employee_id → employees.idPurpose: Retrieve employee information.
• employee_presences.employee_id → leaves.employee_idPurpose: Validate when an employee's status is on leave.
• employee_presences.employee_id → shifts.employee_idPurpose: Compare current presence with clock-in activity.
• employee_presences.employee_id → daily_time_configs.employee_idPurpose: Analyze employee presence together with worked and expected hours.

Key Fields

Features / Relevant Data

• presence_status → workforce availability analysis
• employee_id → employee presence monitoring

Contains the master employee information within the platform. Stores personal details, employment status, contact information, organizational structure, legal entity, management hierarchy, identifiers, and other HR-related data.

This is one of the core tables in the data model and is commonly used as the primary dimension for joining most HR, Payroll, Time Tracking, ATS, and document-related datasets.

Entity

Employees / HR / Workforce Management

Use Cases

• Employee master data reporting
• Headcount analysis
• Workforce segmentation
• Organizational structure reporting
• Employee lifecycle analysis
• HR compliance reporting
• Employee directory
• Cross-module reporting

Keys

Relationships

As one of the central tables in the platform, employees is commonly related to almost every HR module, including:

• contracts.employee_id → employees.idPurpose: Retrieve contractual information.
• leaves.employee_id → employees.idPurpose: Analyze employee absences.
• daily_time_configs.employee_id → employees.idPurpose: Analyze worked hours, balances, and attendance.
• shifts.employee_id → employees.idPurpose: Retrieve transactional clock-in information.
• employee_presences.employee_id → employees.idPurpose: Determine employee availability.
• documents.employee_id → employees.idPurpose: Associate documents with employees.
• employee_costs.employee_id → employees.idPurpose: Analyze payroll cost center allocations.
• additional_compensations.employee_id → employees.idPurpose: Retrieve fixed employee compensations.
• ats_applications.employee_id → employees.idPurpose: Identify candidates hired through ATS.
• company_holidays.employee_id → employees.idPurpose: Associate employee-specific holidays.
• manager_id → employees.idPurpose: Build organizational hierarchy.
• timeoff_manager_id → employees.idPurpose: Identify the employee responsible for approving Time Off requests.

Key Fields

Features / Relevant Data

• status → active/inactive workforce analysis
• office → workforce distribution by location
• legal_entity → legal entity segmentation
• manager_id → organizational hierarchy
• employee_group_name → workforce segmentation
• country → geographical analysis
• tenure_start_date / antiquity → employee tenure analysis
• terminated_on → employee lifecycle analysis
• age → workforce demographics
• custom_field_* → client-specific employee attributes

Daily snapshot of the employees table. Stores employee information as it existed on each day, enabling historical point-in-time reporting.

Entity

Employees / Historical Snapshots

Use Cases

• Daily headcount analysis
• Historical workforce reporting
• Employee lifecycle tracking

Monthly snapshot of the employees table. Stores employee information at a monthly granularity for historical analysis.

Entity

Employees / Historical Snapshots

Use Cases

• Monthly workforce evolution
• Monthly headcount reporting
• Historical HR analytics

Yearly snapshot of the employees table. Stores employee information at a yearly granularity for long-term workforce analysis.

Entity

Employees / Historical Snapshots

Use Cases

• Annual workforce reporting
• Year-over-year headcount analysis
• Historical employee trend analysis

Contains information about expense groups created by employees within the Expenses module. An expense group can contain one or multiple individual expense items related to the same business purpose, simplifying the review, approval, and reimbursement process.

This table stores general information about each group, including its name, description, status, total reimbursable amount, and reimbursement currency.

Entity

Expenses / Expense Groups / Employees

Use Cases

• Employee expense reporting
• Reimbursement request tracking
• Corporate expense analysis
• Approval workflow monitoring
• Expense auditing

Keys

Relationships

• expenses_expensable_groups.employee_id → employees.idPurpose: Retrieve information about the employee who owns the expense group.
• expenses_expensable_groups.id → individual expense tables *(when applicable)*Purpose: Associate the expense group with the individual expenses it contains.

Key Fields

Features / Relevant Data

• status → approval workflow analysis
• reimbursable_amount → reimbursement and cost analysis
• reimbursable_currency → currency distribution
• review_request_at → review timeline analysis
• employee_id → employee expense analysis

Contains detailed information about individual expense items submitted by employees within the Expenses module. Each record represents a single expense, including merchant information, category, amount, taxes, payment method, attached documents, and relationships with projects or expense groups.

This is the primary table for detailed corporate expense analysis.

Entity

Expenses / Expense Items / Employees

Use Cases

• Detailed expense reporting
• Reimbursement analysis
• Corporate expense tracking
• Approval workflow monitoring
• Project cost analysis
• Financial auditing

Keys

Relationships

• expenses_expensables.employee_id → employees.idPurpose: Retrieve the employee who submitted the expense.
• expenses_expensables.group_id → expenses_expensable_groups.idPurpose: Associate the expense with its expense group.
• expenses_expensables.project_id → projects.id *(when applicable)*Purpose: Allocate expenses to projects.
• expenses_expensables.subproject_id → subprojects.id *(when applicable)*Purpose: Allocate expenses to subprojects.
• expenses_expensables.ledger_account_id → Ledger Accounts *(when applicable)*Purpose: Classify expenses for accounting purposes.
• expenses_expensables.card_payment_id → Card Payments *(when applicable)*Purpose: Identify expenses paid using corporate cards.

Key Fields

Features / Relevant Data

• category / subcategory → expense classification
• amount → cost analysis
• vat_amount → tax analysis
• currency → currency distribution
• status → approval workflow analysis
• approved_at → approval timeline analysis
• payment_method → payment method analysis
• merchant_name → vendor analysis
• project_id / subproject_id → project cost allocation
• reimbursable_amount → reimbursement analysis

Contains financial transactions generated within the Expenses module. This table stores transactions associated with bank accounts or corporate cards, including the transaction amount, currency, status, transaction type, and reconciliation information.

It is primarily used to monitor payments, perform bank reconciliations, and link financial transactions to recorded expenses.

Entity

Expenses / Financial Transactions / Payments

Use Cases

• Bank reconciliation
• Payment tracking
• Financial transaction analysis
• Corporate card monitoring
• Financial auditing

Keys

Relationships

• expenses_transactions.card_payment_id → Card Payments *(when applicable)*Purpose: Associate the transaction with a corporate card payment.
• expenses_transactions.category_id → Expense Categories *(when applicable)*Purpose: Classify the transaction into a financial category.
• expenses_transactions.card_payment_id → expenses_expensables.card_payment_idPurpose: Link the financial transaction to the corresponding expense record.

Key Fields

Features / Relevant Data

• amount → financial analysis
• currency → currency distribution
• status → reconciliation monitoring
• transaction_type → financial movement classification
• fully_reconciled_at → reconciliation timeline analysis
• bank_account → bank account analysis

Contains information related to an employee's family situation or marital status. This information is commonly used for payroll, benefits administration, legal compliance, and HR reporting.

Entity

Employees / HR / Family Information

Use Cases

• Demographic reporting
• Employee segmentation
• Payroll configuration
• Benefits analysis
• HR reporting

Keys

Relationships

• family_situations.employee_id → employees.idPurpose: Retrieve the employee associated with the family information.

Key Fields

Features / Relevant Data

• civil_status → demographic segmentation
• employee_id → employee relationship

Contains information about bank accounts configured within the Finance module. It includes account identification details, currency, bank information, beneficiary, different balance types, and the last synchronization date with the financial institution.

This table is primarily used for bank account monitoring, reconciliation processes, and liquidity analysis.

Entity

Finance / Bank Accounts

Use Cases

• Bank account monitoring
• Financial reporting
• Bank reconciliation
• Liquidity analysis
• Balance tracking

Keys

Relationships

• finance_bank_accounts.currency → Financial module currencies.Purpose: Identify the account currency.
• finance_bank_accounts.id → expenses_transactions.bank_account *(when applicable)*Purpose: Associate financial transactions with the corresponding bank account.

Key Fields

Features / Relevant Data

• account_balance_cents → total account balance
• available_balance_cents → available liquidity
• pending_balance_cents → pending transactions
• currency → currency distribution
• bank_name → financial institution analysis
• last_synchronised_at → bank synchronization monitoring

Contains information about payments made using corporate cards within the Finance module. It stores payment amounts, merchant information, currency, approval status, transaction type, and additional details related to validation and reconciliation processes.

This table allows corporate card transactions to be linked with expense records created in the Expenses module.

Entity

Finance / Corporate Cards / Payments

Use Cases

• Corporate card payment tracking
• Expense reconciliation
• Corporate spending analysis
• Merchant spending analysis
• Financial auditing

Keys

Relationships

• finance_card_payments.id → expenses_expensables.card_payment_idPurpose: Associate the corporate card payment with the recorded expense.
• finance_card_payments.id → expenses_transactions.card_payment_idPurpose: Associate the payment with the corresponding financial transaction.
• finance_card_payments.card_id → Corporate Cards *(when applicable)*Purpose: Identify the corporate card used for the payment.

Key Fields

Features / Relevant Data

• amount_cents → spending analysis
• merchant_name → vendor analysis
• approved → approval rate
• status → payment workflow monitoring
• merchant_currency → international spending analysis
• exchange_rate → currency conversion analysis
• type → transaction classification

Contains information about corporate cardholders within the Finance module. It stores the cardholder's contact information and links them to both a bank account and the corresponding employee.

This table acts as the bridge between employees and the corporate cards assigned to them.

Entity

Finance / Cardholders / Employees

Use Cases

• Corporate cardholder management
• Corporate card assignment
• Employee-to-card relationship tracking
• Corporate card auditing
• Linked bank account management

Keys

Relationships

• finance_cardholders.employee_id → employees.idPurpose: Retrieve the employee assigned as the cardholder.
• finance_cardholders.bank_account_id → finance_bank_accounts.idPurpose: Identify the bank account associated with the cardholder.
• finance_cardholders.id → finance_cards.cardholder_idPurpose: Retrieve the corporate cards assigned to the cardholder.

Key Fields

Features / Relevant Data

• employee_id → cardholder assignment
• bank_account_id → bank account relationship
• email → cardholder identification
• phone_country_code → geographical distribution
• phone_number → contact information

Contains information about corporate cards configured within the Finance module. It stores card identification details, cardholder information, status, expiration dates, digital wallet support, and the associated bank account.

This table is used to manage company-issued cards and relate them to payments, financial transactions, and bank accounts.

Entity

Finance / Corporate Cards

Use Cases

• Corporate card management
• Active and inactive card monitoring
• Corporate payment method management
• Financial auditing
• Corporate card reconciliation

Keys

Relationships

• finance_cards.id → finance_card_payments.card_idPurpose: Retrieve all payments made with a specific corporate card.
• finance_cards.bank_account_id → finance_bank_accounts.idPurpose: Identify the bank account linked to the card.
• finance_cards.cardholder_id → employees.id *(when applicable)*Purpose: Identify the employee assigned as the cardholder.

Key Fields

Features / Relevant Data

• status → active/inactive card analysis
• type → card classification
• exp_month / exp_year → expiration monitoring
• apple_pay_enabled → Apple Pay adoption
• google_pay_enabled → Google Pay adoption
• creation_source → card issuance source
• bank_account_id → bank account distribution

The exposer appears as cardhodler_id, but it most likely represents cardholder_id (assigned cardholder). If documenting the raw schema, keep the original exposer name and optionally note the apparent typo.

Contains the financial categories used within the Finance module to classify transactions, expenses, and other financial movements. Categories can be organized hierarchically using parent-child relationships, allowing for a structured financial classification.

This table helps standardize and organize financial information for reporting and accounting purposes.

Entity

Finance / Categories

Use Cases

• Expense classification
• Transaction classification
• Financial reporting
• Accounting
• Category-based analysis

Keys

Relationships

• finance_categories.id → expenses_transactions.category_idPurpose: Classify financial transactions.
• finance_categories.parent_category_id → finance_categories.idPurpose: Build the category hierarchy (parent/child).

Key Fields

Features / Relevant Data

• label → financial classification
• protected → system category identification
• visible → user availability
• enabled → active/inactive category analysis
• parent_category_id → category hierarchy

Contains the Chart of Accounts (Ledger Accounts) used within the Finance module. These accounts are used to classify expenses, financial transactions, and other accounting movements, while also being associated with specific legal entities.

This table is essential for accounting integrations and financial reporting.

Entity

Finance / Ledger Accounts / Accounting

Use Cases

• Expense accounting classification
• Accounting integrations
• Financial reporting
• Legal entity segmentation
• Financial auditing

Keys

Relationships

• finance_ledger_accounts.id → expenses_expensables.ledger_account_idPurpose: Classify expenses for accounting purposes.
• finance_ledger_accounts.legal_entity_id → employees.legal_entity_id *(when applicable)*Purpose: Associate ledger accounts with a specific legal entity.
• finance_ledger_accounts.parent_legal_entity_id → Parent Legal Entities *(when applicable)*Purpose: Organize ledger accounts according to the organizational structure.

Key Fields

Features / Relevant Data

• type → accounting classification
• currency → currency analysis
• legal_entity_id → legal entity segmentation
• number → accounting identification
• external_id → external integration reference

Contains the monthly summary for employees subject to the Forfait Jours working scheme. It records, for each day of the month, whether the employee worked, was absent, and the corresponding leave type.

This table is intended for employees whose workload is measured in worked days rather than worked hours, making it particularly useful for labor compliance in countries such as France.

Entity

Time Tracking / Forfait Jours

Use Cases

• Forfait Jours reporting
• Worked day tracking
• Leave monitoring
• Labor compliance
• Monthly activity summaries

Keys

Relationships

• forfait_jours_by_months.employee_id → employees.idPurpose: Retrieve employee information.
• forfait_jours_by_months.employee_id + date → leaves.employee_idPurpose: Retrieve leave details recorded for the day.
• forfait_jours_by_months.employee_id + date → daily_time_configs.employee_id *(when applicable)*Purpose: Compare worked days with recorded activity.
• forfait_jours_by_months.employee_id + date → shifts.employee_id *(when applicable)*Purpose: Validate attendance records for the day.

Key Fields

Features / Relevant Data

• shift_worked → worked day analysis
• absence_duration → leave analysis
• absence_type → leave classification
• date → monthly activity analysis

Contains a daily snapshot of the data stored in forfait_jours_by_months. It allows historical analysis by preserving the state of Forfait Jours records as they existed during a specific period, making it suitable for auditing and retrospective reporting.

Entity

Time Tracking / Forfait Jours Snapshot

Use Cases

• Historical auditing
• Historical Forfait Jours reporting
• Activity comparisons
• Change tracking
• Compliance analysis

Keys

Relationships

• forfait_jours_by_months_cohort_by_day.employee_id → employees.idPurpose: Retrieve employee information.
• forfait_jours_by_months_cohort_by_day.employee_id + date → leaves.employee_id *(when applicable)*Purpose: Retrieve the corresponding leave information.
• forfait_jours_by_months_cohort_by_day.employee_id + date → daily_time_configs.employee_id *(when applicable)*Purpose: Compare historical records with daily tracked activity.
• forfait_jours_by_months_cohort_by_day.employee_id + date → shifts.employee_id *(when applicable)*Purpose: Validate attendance records for the day.

Key Fields

Features / Relevant Data

• shift_worked → historical worked day analysis
• absence_duration → historical leave analysis
• absence_type → historical leave classification
• cohort_start_date / cohort_end_date → represented snapshot period

Contains a monthly snapshot of the data stored in forfait_jours_by_months. It preserves the historical state of Forfait Jours records at the end of each month, making it suitable for retrospective analysis, monthly comparisons, and auditing.

Entity

Time Tracking / Forfait Jours Snapshot

Use Cases

• Historical monthly reporting
• Auditing
• Monthly comparisons
• Activity tracking
• Compliance analysis

Keys

Relationships

• forfait_jours_by_months_cohort_by_month.employee_id → employees.idPurpose: Retrieve employee information.
• forfait_jours_by_months_cohort_by_month.employee_id + date → leaves.employee_id *(when applicable)*Purpose: Retrieve the corresponding leave information.
• forfait_jours_by_months_cohort_by_month.employee_id + date → daily_time_configs.employee_id *(when applicable)*Purpose: Compare historical records with daily tracked activity.
• forfait_jours_by_months_cohort_by_month.employee_id + date → shifts.employee_id *(when applicable)*Purpose: Validate attendance records for the day.

Key Fields

Features / Relevant Data

• shift_worked → historical worked day analysis
• absence_duration → historical leave analysis
• absence_type → historical leave classification
• cohort_start_date / cohort_end_date → represented snapshot period

Contains a yearly snapshot of the data stored in forfait_jours_by_months. It preserves the historical state of Forfait Jours records for each year, making it suitable for long-term analysis, auditing, and year-over-year comparisons.

Entity

Time Tracking / Forfait Jours Snapshot

Use Cases

• Historical yearly reporting
• Auditing
• Year-over-year comparisons
• Activity tracking
• Compliance analysis

Keys

Relationships

• forfait_jours_by_months_cohort_by_year.employee_id → employees.idPurpose: Retrieve employee information.
• forfait_jours_by_months_cohort_by_year.employee_id + date → leaves.employee_id *(when applicable)*Purpose: Retrieve the corresponding leave information.
• forfait_jours_by_months_cohort_by_year.employee_id + date → daily_time_configs.employee_id *(when applicable)*Purpose: Compare historical records with daily tracked activity.
• forfait_jours_by_months_cohort_by_year.employee_id + date → shifts.employee_id *(when applicable)*Purpose: Validate attendance records for the day.

Key Fields

Features / Relevant Data

• shift_worked → historical worked day analysis
• absence_duration → historical leave analysis
• absence_type → historical leave classification
• cohort_start_date / cohort_end_date → represented snapshot period

Contains the yearly summary for employees subject to the Forfait Jours working scheme. It records the total number of worked days during the year, the accumulated balance, and the contract used to perform the calculation.

This table is designed to analyze annual compliance with the Forfait Jours scheme, where working time is measured in days rather than hours.

Entity

Time Tracking / Forfait Jours

Use Cases

• Yearly Forfait Jours reporting
• Worked day tracking
• Annual balance monitoring
• Labor compliance
• Auditing
• Year-over-year analysis

Keys

Relationships

• forfait_jours_by_years.employee_id → employees.idPurpose: Retrieve employee information.
• forfait_jours_by_years.contract_id → contracts.idPurpose: Retrieve the contractual conditions associated with the yearly calculation.
• forfait_jours_by_years.employee_id → forfait_jours_by_months.employee_idPurpose: Compare the yearly summary with the monthly breakdown.

Key Fields

Features / Relevant Data

• worked_days_in_year → yearly worked day analysis
• balance → annual balance monitoring
• year → historical and year-over-year analysis

Contains the Goal Metric Groups used in the Performance module. Each record represents a parent goal that groups one or more individual metrics (goals_metrics), allowing the overall progress of an initiative or objective to be evaluated.

Entity

Performance / Goals

Use Cases

• Goal tracking
• Performance reviews
• Performance dashboards
• Goal achievement analysis
• OKR and objective tracking
• Progress reporting

Keys

Relationships

• goals_metric_groups.id → goals_metrics.metric_group_idPurpose: Retrieve all metrics associated with the same goal.

Key Fields

Features / Relevant Data

• progress → overall progress tracking
• needs_attention → identify goals at risk
• title → goal classification

Contains the historical values recorded for each performance metric (goals_metrics). Each record represents an update to a metric at a specific point in time, allowing its progression to be analyzed over time.

Entity

Performance / Goals / Metric History

Use Cases

• Historical goal tracking
• Performance trend analysis
• Change auditing
• Progress analysis
• Performance dashboards
• Initial vs current vs target value comparison

Keys

Relationships

• goals_metric_values.metric_id → goals_metrics.idPurpose: Retrieve the metric associated with the recorded value.
• goals_metrics.metric_group_id → goals_metric_groups.id *(through goals_metrics)*Purpose: Analyze the evolution of metrics belonging to the same goal.

Key Fields

Features / Relevant Data

• quantitative_current_value → performance evolution
• quantitative_target_value → target comparison
• created_at → historical trend analysis
• qualitative_value → qualitative metric tracking

Contains information about Goal Metrics configured in Factorial. Each record represents an individual metric assigned to an employee, including its evaluation period, progress, target values, and current status.

This table is used to monitor performance for both quantitative and qualitative goals.

Entity

Performance / Goals / Metrics

Use Cases

• Goal tracking
• Performance reviews
• Progress dashboards
• Goal achievement analysis
• Expected vs actual progress analysis
• Performance reporting

Keys

Relationships

• goals_metrics.assignee_id → employees.idPurpose: Retrieve information about the employee responsible for the goal.
• goals_metrics.metric_group_id → Goal Metric Groups *(when available)*Purpose: Group metrics belonging to the same goal or initiative.

Key Fields

Features / Relevant Data

• progress → progress tracking
• expected_progress → expected vs actual comparison
• progress_status → completion status
• quantitative_target_value → target measurement
• quantitative_current_value → current performance
• type → goal type classification

Contains the calculated results generated by the company's Time Tracking policies for each employee and working day. The table breaks down tracked time according to the rules configured by the company, classifying it into regular time, overtime, public holiday time, and any other special working hour rules defined in the attendance policies.

Each record represents a calculation rule applied to an employee on a specific date, meaning that a single employee may have multiple records for the same day.

Entity

Time Tracking / Attendance Policies / Hour Calculations

Use Cases

• Overtime reporting
• Special Working Hours (Majorations) reporting
• Regular vs overtime analysis
• Daily balance calculations
• Attendance policy validation
• Worked time analysis by calculation rule

Keys

Relationships

• hour_breakdowns.employee_id → employees.idPurpose: Retrieve employee information.
• hour_breakdowns.date → daily_time_configs.date + employee_id *(when applicable)*Purpose: Compare the hour breakdown against daily time calculations.
• hour_breakdowns.date → shifts.reference_date + employee_id *(when applicable)*Purpose: Link the calculated results to the original clock-in records.

Key Fields

Features / Relevant Data

• effective_extra_time → overtime analysis
• effective_regular_time → regular hours analysis
• scheduled_overtime → planned vs actual overtime
• requested_overtime → overtime request tracking
• balance → daily balance monitoring
• time_range_type → rule classification
• time_range_name → attendance policy analysis
• bank_holiday_time_in_range → public holiday work
• custom_time_in_range → company-defined special rules

Contains all information related to employee leave requests. It includes the leave type, request status, duration, start and end dates, as well as information about supporting documentation.

This is the primary table used to analyze vacations, sick leave, paid leave, and any other absence managed through the Time Off module.

Entity

Time Off / Leaves / Employees

Use Cases

• Leave reporting
• Vacation reporting
• Absenteeism analysis
• Leave day and hour calculations
• Approval tracking
• Leave auditing

Keys

Relationships

• leaves.employee_id → employees.idPurpose: Retrieve employee information.
• leaves.id → documents.leave_idPurpose: Retrieve supporting documents attached to the leave request.
• leaves.employee_id + start_on / finish_on → contracts.employee_idPurpose: Retrieve the applicable contract to correctly calculate working days and working hours during the leave period.
• leaves.employee_id + date → daily_time_configs.employee_idPurpose: Compare leave periods against planned hours, worked hours, and daily balances.
• leaves.employee_id + date → shifts.employee_idPurpose: Validate clock-ins during leave periods and identify attendance issues.
• leaves.employee_id + date → shift_management_shifts.employee_idPurpose: Retrieve assigned shifts during the leave period.
• leaves.employee_id + date → work_schedule_schedules.employee_idPurpose: Retrieve the employee's planned working schedule.
• leaves.employee_id + date → company_holidays.employee_id *(when applicable)*Purpose: Identify public holidays overlapping with the leave period.

Key Fields

Features / Relevant Data

• leave_type_name → leave type analysis
• status → approval tracking
• duration → duration analysis
• duration_type → duration classification
• document_justified → documentation compliance
• start_on / finish_on → time-based analysis
• created_at → request timeline analysis

Contains a daily snapshot of the leaves dataset. It allows historical analysis by preserving the state of leave records as they existed on a specific day.

Entity

Time Off / Leaves Snapshot

Contains a monthly snapshot of the leaves dataset. It enables historical reporting by preserving the state of leave records at the end of each month.

Entity

Time Off / Leaves Snapshot

Contains a yearly snapshot of the leaves dataset. It allows long-term historical analysis without relying solely on the current state of leave records.

Entity

Time Off / Leaves Snapshot

Contains the Workplaces (Locations) configured within Factorial. Each record represents a physical workplace where employees can be assigned, including address information, time zone, and geographic coordinates.

This table centralises information about the company's offices, branches, and work locations.

Entity

Organisation / Workplaces / Locations

Use cases

• Workplace reporting
• Employee geographic distribution
• Office and branch analysis
• Country, state, and city segmentation
• Workplace management

Keys

Relationships

• locations.name → employees.office *(when applicable)*Purpose: Retrieve the workplace assigned to an employee.
• locations.country → employees.country *(when applicable)*Purpose: Geographic reporting and country-based segmentation.
• locations.timezone → Time Tracking *(when applicable)*Purpose: Consider the workplace time zone in attendance and clock-in processes.

Key fields

Features / Relevant data

• country → country analysis
• state → regional segmentation
• city → geographic distribution
• main → primary workplace identification
• timezone → time zone analysis
• latitude / longitude → geolocation

Notes

• Each record represents a workplace configured in Factorial.
• Frequently used together with employees to segment reports by office, branch, or workplace.
• Can be used to build geographic reports and analyze employee distribution across locations.
• The timezone field is particularly useful for Time Tracking implementations and organizations operating across multiple time zones.
• latitude and longitude enable integration with mapping services and geospatial analysis tools.

Contains employee observations or notes recorded within Factorial. Each record represents a comment associated with an employee on a specific date, providing a historical log of internal notes.

These observations can be used to document follow-ups, incidents, recognition, or any other relevant information related to an employee.

Entity

Employees / Observations

Use cases

• Employee follow-up
• Incident tracking
• Observation history
• Audit reporting
• Employee monitoring
• Internal performance reviews

Keys

Relationships

• observations.employee_id → employees.idPurpose: Retrieve information about the associated employee.

Key fields

Features / Relevant data

• observation → note analysis
• date → chronological tracking
• employee_id → employee history

Notes

• Each record represents a single observation associated with an employee.
• An employee may have multiple observations recorded over time.
• The observation field contains free-text information, so its content depends entirely on how each organization uses the feature.
• It can be used to document incidents, recognition, follow-up notes, or any other relevant employee-related information.
• This table is commonly used together with employees to build employee history and follow-up reports.

Contains employee overtime requests. Each record represents an overtime request submitted for a specific date, including the requested hours, request status, and the justification provided by the employee.

This table stores overtime requests regardless of whether they are approved, rejected, or still pending.

Entity

Time Tracking / Overtime

Use cases

• Overtime request reporting
• Approval tracking
• Request auditing
• Requested overtime analysis
• Productivity reporting

Keys

Relationships

• overtime_requests.employee_id → employees.idPurpose: Retrieve employee information.
• overtime_requests.employee_id + date → shifts.employee_id *(when applicable)*Purpose: Validate the worked shift that generated the overtime request.
• overtime_requests.employee_id + date → daily_time_configs.employee_id *(when applicable)*Purpose: Compare requested overtime against tracked hours and daily balances.
• overtime_requests.employee_id + date → hour_breakdowns.employee_id *(when applicable)*Purpose: Compare requested overtime against the overtime calculated by the Time Tracking policies.

Key fields

Features / Relevant data

• hours → requested overtime analysis
• status → approval tracking
• reason → request categorisation
• date → time trend analysis

Notes

• Each record represents one overtime request.
• This table stores requested overtime only and does not represent the overtime actually worked or calculated.
• It is commonly combined with hour_breakdowns, daily_time_configs, and shifts to compare requested overtime with tracked hours and overtime calculated by the company's Time Tracking policies.
• Depending on the company's workflow, requests may have statuses such as pending, approved, or rejected.
• This table is particularly useful for auditing the overtime approval process and analyzing the difference between requested overtime and recognized overtime.

Contains the employee identifiers used by the different Payroll integration providers supported by Factorial. Each field stores the employee code assigned by a specific payroll provider, allowing employee records to be synchronised between Factorial and external payroll systems.

This table does not contain salary information or payroll calculations; it only stores the identifiers required by each integration.

Entity

Payroll / Integrations

Use cases

• Payroll integration auditing
• Synchronisation validation
• Employee matching between Factorial and external payroll systems
• Integration configuration reporting
• Synchronisation troubleshooting

Keys

Relationships

• payroll_integrations.employee_id → employees.idPurpose: Retrieve information about the employee associated with each payroll integration.

Key fields

Features / Relevant data

• Stores the employee identifier used by different payroll providers.
• An employee will typically have a value only for the payroll system configured by the company.
• Facilitates data reconciliation between Factorial and external payroll platforms.

Notes

• This table is intended exclusively for Payroll integrations.
• It does not contain salary data, payroll items, payments, or financial information.
• Depending on the company's configured integrations, many of these fields may remain empty.
• It is primarily used to validate integration setups, troubleshoot synchronization issues, and map employees between Factorial and external payroll systems.
• It is commonly used together with employees to identify the corresponding employee.

Contains the responses submitted during Performance Reviews. Each record represents the answer provided to a specific question within an evaluation, including the main answer and an optional comment.

This table stores the actual responses submitted by reviewers and reviewees, allowing a completed evaluation to be fully reconstructed.

Entity

Performance / Performance Reviews

Use cases

• Performance review result reporting
• Response auditing
• Performance analysis
• Evaluation tracking
• Result exports
• Performance dashboards

Keys

Relationships

• performance_review_evaluation_answers.evaluation_id → performance_review_evaluations.idPurpose: Retrieve the evaluation associated with the response.
• performance_review_evaluation_answers.question_uuid → performance_review_questions.uuidPurpose: Retrieve the corresponding question.
• performance_review_evaluations.review_process_id → performance_review_processes.id *(through performance_review_evaluations)*Purpose: Identify the Performance Review process associated with the response.

Key fields

Features / Relevant data

• answer → submitted response
• answer_comment → additional feedback
• question_uuid → link to the original question
• evaluation_id → link to the corresponding evaluation

Notes

• Each record represents the answer to a single question within a Performance Review evaluation.
• The content of answer depends on the question type defined in performance_review_questions; it may contain free text, a rating, a selected option, or another supported response format.
• answer_comment stores optional comments when the review form allows additional feedback.
• To reconstruct a complete evaluation, this table is commonly joined with performance_review_questions and performance_review_evaluations.
• It can also be related to performance_review_processes to provide the context of the overall review cycle.
• This is the primary table used to analyze Performance Review results and generate detailed reports based on employee responses.

Contains information about individual performance evaluations performed within Performance Review processes in Factorial. Each record represents a single evaluation between a reviewer and a reviewee, including the evaluation type, its current status, and the review process it belongs to.

This table allows you to analyse who evaluates whom, the status of each evaluation, and its relationship to a specific performance review process.

Entity

Performance / Performance Reviews

Use cases

• Performance review tracking
• Review process auditing
• Pending and completed evaluation reporting
• Reviewer and reviewee analysis
• Participation metrics
• Performance dashboards

Keys

Relationships

• performance_review_evaluations.reviewer_employee_id → employees.idPurpose: Retrieve reviewer information.
• performance_review_evaluations.target_employee_id → employees.idPurpose: Retrieve reviewee information.
• performance_review_evaluations.review_process_id → performance_review_processes.id *(when available)*Purpose: Retrieve information about the associated performance review process.

Key fields

Features / Relevant data

• evaluation_type → evaluation type classification
• status → evaluation progress tracking
• reviewer_employee_id → reviewer analysis
• target_employee_id → reviewee analysis

Notes

• Each record represents a single evaluation within a Performance Review process.
• The same employee may participate as a reviewer, a reviewee, or both, depending on the review workflow.
• evaluation_type distinguishes different review models, such as self-reviews, manager reviews, and peer reviews.
• This table is commonly joined with employees to retrieve additional information about both reviewers and reviewees.
• It is also frequently related to performance_review_processes to obtain details about the review cycle, including dates, configuration, and overall process status.
• It is particularly useful for building Performance dashboards, measuring participation rates, and auditing performance review processes.

Contains the final performance score assigned to each employee after completing a Performance Review process. Each record represents the consolidated result for an employee within a review cycle, including the final score, the scoring scale used, the normalized score, and the calculation timestamp.

This table stores the final outcome of the review process once all evaluations have been completed and processed.

Entity

Performance / Performance Reviews

Use cases

• Performance reporting
• Employee rankings
• Final score analysis
• Performance dashboards
• Performance review auditing
• Review cycle comparisons

Keys

Relationships

• performance_review_final_employee_scores.target_employee_id → employees.idPurpose: Retrieve information about the reviewed employee.
• performance_review_final_employee_scores.review_process_id → performance_review_processes.idPurpose: Retrieve information about the associated Performance Review process.
• performance_review_final_employee_scores.target_employee_id + review_process_id → performance_review_evaluations.target_employee_id *(when applicable)*Purpose: Relate the final score to the individual evaluations that contributed to it.

Key fields

Features / Relevant data

• score → employee's final performance result
• normalized_score → comparison across different scoring scales
• calculated_at → calculation audit trail
• scale_min / scale_max → score interpretation

Notes

• Each record represents the final consolidated performance score for an employee within a Performance Review process.
• Unlike performance_review_evaluations, which stores individual reviews, this table contains the final calculated score for the employee.
• normalized_score enables comparisons between review processes that use different scoring scales.
• This table is commonly joined with performance_review_processes to identify the review cycle and with employees to retrieve employee information.
• It can also be combined with performance_review_evaluations and performance_review_evaluation_answers to analyze how individual evaluations contributed to the final score.
• It is particularly useful for generating employee rankings, Performance dashboards, historical comparisons, and overall performance analytics.

Contains information about Performance Review processes (review cycles) configured in Factorial. Each record represents a review cycle, including its name, description, execution period, current status, and whether it has been archived.

This table represents the top level of the Performance Review hierarchy and groups all individual evaluations performed within the same review cycle.

Entity

Performance / Performance Reviews

Use cases

• Performance review cycle management
• Performance process reporting
• Review campaign tracking
• Performance auditing
• Performance dashboards
• Participation analysis by review cycle

Keys

Relationships

• performance_review_processes.id → performance_review_evaluations.review_process_idPurpose: Retrieve all evaluations belonging to the same review process.

Key fields

Features / Relevant data

• status → process status tracking
• starts_at / ends_at → review period analysis
• archived → historical process identification
• name → review campaign classification

Notes

• Each record represents an entire Performance Review cycle.
• A single process can contain multiple individual evaluations, which are stored in performance_review_evaluations.
• The status field identifies the current stage of the review process, such as draft, active, completed, or other platform-defined statuses.
• The archived field distinguishes active review cycles from historical ones that have already been closed.
• This table is commonly used together with performance_review_evaluations to retrieve all evaluations associated with a specific review cycle.
• It is particularly useful for participation reporting, monitoring review campaign progress, and auditing historical Performance Review processes.

Contains the questions configured for Performance Review processes in Factorial. Each record represents a question that belongs to a review process, including its type, whether it is mandatory, the evaluation type it applies to, and the configuration of its possible answers.

This table defines the structure of the questionnaires used during Performance Reviews.

Entity

Performance / Performance Reviews

Use cases

• Review questionnaire auditing
• Performance review reporting
• Question type analysis
• Performance process documentation
• Evaluation configuration validation

Keys

Relationships

• performance_review_questions.review_process_id → performance_review_processes.idPurpose: Retrieve the Performance Review process associated with the question.

Key fields

Features / Relevant data

• question_type → question classification
• mandatory → required question identification
• evaluation_type → evaluation type segmentation
• choice_options → configured answer options
• scale → rating scale configuration

Notes

• Each record represents a single question within a Performance Review process.
• A review process can contain multiple questions.
• The question behavior depends on its question_type, supporting free-text answers, rating scales, multiple-choice questions, and other configurable formats.
• choice_options typically stores the available answer choices for selection-based questions and may be represented as structured text or JSON.
• evaluation_type allows questions to be displayed only for specific review types, such as self-reviews, manager reviews, or peer reviews.
• This table is commonly used together with performance_review_processes to reconstruct the complete structure of a Performance Review questionnaire.

Contains consolidated information about employees assigned to projects within the Project Management module. Each record represents an employee's participation in a project, including tracked time, labor costs, and recorded spending.

Unlike project_workers, this table includes financial metrics that allow organisations to analyse the actual cost of the resources assigned to each project.

Entity

Project Management / Project Workers

Use cases

• Project cost reporting
• Profitability analysis
• Resource allocation analysis
• Employee productivity reporting
• Labor cost analysis
• Financial dashboards
• Project allocation reporting

Keys

Relationships

• project_management__project_workers.employee_id → employees.idPurpose: Retrieve employee information.
• project_management__project_workers.project_id → projects.idPurpose: Retrieve project information.
• project_management__project_workers.employee_id → shifts.employee_id *(report correlation)*Purpose: Correlate employee shifts to build productivity, utilization, and project time reports.
• project_management__project_workers.project_id → project_time_records *(through project_worker_id when applicable)*Purpose: Analyze the detailed project time allocations recorded by the employee.

Key fields

Features / Relevant data

• inputed_minutes → total allocated time
• labor_cost_cents → allocated labor cost
• company_labor_cost_cents → total company labor cost
• spending_cost_cents → recorded project expenses
• assigned → assignment status

Notes

• Each record represents an employee assigned to a project.
• In addition to assignment information, this table provides financial metrics for analyzing project resource costs.
• Fields ending in _cents are stored in the smallest currency unit (for example, cents) and typically need to be divided by 100 to obtain the monetary amount.
• This table is commonly joined with projects to retrieve project information and with employees to enrich employee details.
• It can be combined with project_time_records to analyze both summarized and detailed project time allocations.
• It is one of the primary tables used to build project cost reports, profitability analyses, and financial project dashboards.

Contains the detailed flexible time allocations recorded by employees against projects and subprojects. Unlike project_time_records, these records are not linked to an attendance shift, representing manually entered or independently recorded project time.

This table allows employees to allocate time to projects even when no attendance record exists.

Entity

Projects / Flexible Time Tracking

Use cases

• Flexible project time reporting
• Subproject time reporting
• Employee productivity analysis
• Workload distribution
• Resource utilisation analysis
• Operational dashboards
• Manual time allocation auditing

Keys

Relationships

• project_flexible_time_records.project_worker_id → project_workers.idPurpose: Retrieve the employee and project associated with the time allocation.
• project_flexible_time_records.subproject_id → subprojects.idPurpose: Retrieve the associated subproject.
• project_workers.project_id → projects.id *(through project_workers)*Purpose: Retrieve the parent project associated with the recorded time.

Key fields

Features / Relevant data

• imputed_minutes → allocated project time
• date → time-based analysis
• project_worker_id → associated employee and project
• subproject_id → subproject segmentation

Notes

• Each record represents a single flexible time allocation made against a project.
• Unlike project_time_records, this table is not linked to attendance records (shifts), making these allocations independent from employee clock-ins.
• It is commonly joined with project_workers to identify the employee responsible for the allocation and the corresponding project.
• When subproject_id is available, allocations can be analyzed at the subproject level.
• This table is particularly useful for organizations that allow manual project time entries or do not require all project work to originate from attendance tracking.
• It is commonly used to build productivity reports, workload analyses, resource utilization dashboards, and manual project time allocation reports.

Contains consolidated information about projects managed within Factorial's Project Management module. Unlike the projects table, this dataset includes financial and operational indicators that allow organisations to analyse project performance, costs, and profitability.

In addition to general project information, it provides tracked time, labor costs, spending, fixed costs, and billing configuration.

Entity

Project Management / Projects

Use cases

• Project financial reporting
• Profitability analysis
• Cost control
• Project monitoring
• Executive dashboards
• Productivity reporting
• Billing analysis

Keys

Relationships

• project_management__projects.id → project_management__project_workers.project_idPurpose: Retrieve employees assigned to the project.
• project_management__projects.id → projects.id *(when both datasets are available)*Purpose: Complement the project's operational information.
• project_management__projects.legal_entity_id → employees.legal_entity_idPurpose: Relate the project to its corresponding legal entity.

Key fields

Features / Relevant data

• inputed_minutes → total tracked time
• employees_assignment → number of assigned employees
• is_billable → identifies billable projects
• fixed_cost_cents → fixed costs
• labor_cost_cents → labor costs
• spending_cost_cents → recorded expenses
• total_cost_cents → consolidated project cost
• billable_rate_type → billing configuration

Notes

• Each record represents a project within the Project Management module.
• Unlike the projects table, this dataset includes financial indicators and business metrics for analyzing project profitability and performance.
• Fields ending in _cents store values in the smallest currency unit (for example, cents) and typically need to be divided by 100 to obtain the monetary amount.
• This table is commonly joined with project_management__project_workers to analyze employee allocation, tracked time, and labor costs.
• When available, it can be combined with projects to enrich operational project information.
• It is one of the primary datasets used for financial dashboards, profitability analysis, cost control, executive reporting, and project performance monitoring.

Contains the detailed time entries recorded against projects and subprojects. Each record represents a time allocation made by an employee on a specific date, typically linked to an attendance shift.

This is the most granular table within the Projects module for tracking project-related work, allowing users to identify exactly how many minutes were allocated, on which date, to which project, and, when applicable, to which subproject.

Entity

Projects / Time Tracking

Use cases

• Project time reporting
• Subproject time reporting
• Employee productivity analysis
• Resource utilisation reporting
• Workload distribution
• Operational dashboards
• Time allocation auditing

Keys

Relationships

• project_time_records.project_worker_id → project_workers.idPurpose: Retrieve the employee and project associated with the time entry.
• project_time_records.attendance_shift_id → shifts.id *(attendance shift)*Purpose: Retrieve the attendance shift that originated the time allocation.
• project_time_records.subproject_id → subprojects.idPurpose: Retrieve the associated subproject.
• project_workers.project_id → projects.id *(through project_workers)*Purpose: Retrieve the parent project for the recorded time.

Key fields

Features / Relevant data

• imputed_minutes → recorded working time
• date → time-based analysis
• attendance_shift_id → link to the original attendance record
• project_worker_id → associated employee and project
• subproject_id → subproject segmentation

Notes

• Each record represents a single time allocation made against a project.
• This is the most detailed table available for analyzing project time tracking.
• It is commonly joined with project_workers to identify the employee responsible for the recorded time and the project to which it belongs.
• It is also frequently combined with shifts through attendance_shift_id to retrieve additional attendance information such as clock-in/out times, worked hours, and other Time Tracking metrics.
• When subproject_id is populated, time allocations can be analyzed at the subproject level for more granular reporting.
• This table is one of the primary sources for building productivity reports, workload analyses, resource utilization dashboards, and project time allocation reporting.

Contains information about employees assigned to projects in Factorial. Each record represents the relationship between an employee and a project, indicating whether the assignment is active and the total amount of time logged by that employee for the project.

This table allows you to identify which employees participate in each project and analyse their level of allocation.

Entity

Projects / Employee Assignment

Use cases

• Project assignment reporting
• Employee allocation analysis
• Project participation tracking
• Workload distribution
• Productivity dashboards
• Resource utilisation analysis

Keys

Relationships

• project_workers.project_id → projects.idPurpose: Retrieve project information.
• project_workers.employee_id → employees.idPurpose: Retrieve employee information.
• project_workers.employee_id → shifts.employee_id *(report correlation)*Purpose: Correlate employee shifts to build productivity, utilization, workload, and project time reports.

Key fields

Features / Relevant data

• assigned → assignment status
• inputed_minutes → total employee allocation
• project_id → associated project
• employee_id → participating employee

Notes

• Each record represents the assignment of an employee to a project.
• assigned indicates whether the assignment is currently active.
• inputed_minutes stores the total amount of time logged by the employee for the project.
• This table is commonly used together with projects to identify the employees assigned to each project.
• It is also frequently correlated with shifts through employee_id to build productivity, workload allocation, resource utilization, and project time reports.
• It is one of the primary tables used to analyze employee participation in projects and to build resource allocation dashboards.

Contains information about the projects configured in Factorial. Each record represents a project that can be used to organise employee work, analyse time allocation, associate expenses, and monitor project activities, depending on the modules enabled by the company.

This table allows users to identify projects, monitor their status, define execution dates, and analyse the total amount of tracked time associated with each project.

Entity

Projects

Use cases

• Project reporting
• Project time analysis
• Project cost analysis
• Employee allocation
• Productivity dashboards
• Operational reporting
• Expense reporting by project

Keys

Relationships

• projects.id → expenses_expensables.project_idPurpose: Retrieve expenses associated with the project.
• projects + shifts.employee_id *(report correlation)*Purpose: Correlate employee shifts with projects to build productivity, utilisation, workload, and project time reports.
• projects.id → subprojects.project_id *(when applicable)*Purpose: Retrieve the subprojects belonging to the project.

Key fields

Features / Relevant data

• inputed_minutes → total tracked time
• status → project lifecycle monitoring
• code → project identification
• start_date / due_date → planning and execution analysis

Notes

• Each record represents a single project configured in Factorial.
• inputed_minutes stores the total amount of tracked time recorded for the project.
• This table is commonly used together with shifts by correlating records through employee_id to build productivity, workload allocation, resource utilisation, and project time reports.
• It is also frequently combined with expenses_expensables to calculate project costs, reimbursements, and expense allocations.
• Depending on the modules enabled by the company, Projects can be used alongside the Time Tracking and Expenses features.
• It is one of the primary tables used to build operational dashboards, productivity analyses, project utilisation reports, and project cost reporting.

Contains information about the employees associated with training sessions in Factorial's Training module. Each record represents an employee membership or access record for a specific training session, including participation status and the relationship between employees and training activities.

This table works as a bridge between sessions and employees, allowing organisations to analyse employee assignments, participation status, training access, and learning activity.

Training program information should be retrieved through the related sessions and trainings tables.

Entity

Training Session Participants

Use cases

• Employee training tracking
• Training participation reporting
• Training compliance analysis
• Employee learning dashboards
• Training assignment monitoring
• Learning & Development reporting
• Training completion analysis

Keys

Relationships

• session_access_memberships.session_id → sessions.idPurpose: Retrieve the training session assigned to the employee, including schedule, modality, and session details.
• session_access_memberships.employee_id → employees.idPurpose: Retrieve employee information associated with the training participation.
• sessions.training_id → trainings.id *(through sessions)*Purpose: Retrieve the training program associated with the employee session participation.

Key fields

Features / Relevant data

• employee_id → connects training activity with employee information.
• session_id → identifies the specific training session assigned to the employee.
• status → tracks employee access or participation status.
• training_id → allows grouping participation by training program when available.
• access_id → identifies the employee training access record.
• session_id + employee_id → enables employee-level training participation analysis.

Notes

• Each record represents one employee relationship with a training session.
• This table acts as the bridge between sessions and employees.
• Multiple employees can be associated with the same training session.
• One employee can have multiple training session memberships.
• Training program details should preferably be retrieved through sessions.training_id → trainings.id.
• Employee information should be enriched by joining employee_id with the employees table.
• status should be used to analyze employee participation, access state, or training progress depending on the configured workflow.
• This dataset is commonly used together with sessions and trainings to build complete Learning & Development reports.
• It is one of the primary tables for employee training assignment analysis, compliance dashboards, and participation tracking.

Contains information about the training sessions configured in Factorial's Training module. Each record represents an individual session belonging to a training program, including scheduling information, duration, modality, location, and subsidy information.

This table represents the execution and scheduling layer of a training program. General training information such as costs, provider details, classification, and status should be retrieved from the related trainings table.

Employee participation and access information should be retrieved through session_access_memberships.

Entity

Training Sessions

Use Cases

• Training calendar reporting
• Training planning analysis
• Learning & Development dashboards
• Training hours analysis
• Training modality reporting
• Training compliance monitoring
• Training activity tracking

Keys

Relationships

• sessions.training_id → trainings.idPurpose: Retrieve the training program associated with the session. Allows combining session scheduling information with training details such as costs, provider, type, and status.
• sessions.id → session_access_memberships.session_idPurpose: Retrieve employees assigned, enrolled, or granted access to a specific training session.
• session_access_memberships.employee_id → employees.idPurpose: Retrieve employee information associated with the training session participation.

Key fields

Features / Relevant data

• starts_at / ends_at → training scheduling and calendar analysis.
• duration → planned learning hours for the session.
• modality → training format analysis (online, onsite, hybrid).
• subsidized → identifies subsidized training sessions.
• location → training venue analysis.
• training_id → groups multiple sessions belonging to the same training program.
• session_access_memberships → provides employee assignment and participation information.

Notes

• Each record represents a single training session configured in Factorial.
• A training program can contain multiple sessions with different dates, locations, and modalities.
• General training information such as costs, provider information, and training classification should be retrieved from trainings.
• Employee participation, access status, and assigned employees are not stored directly in this table and should be retrieved through session_access_memberships.
• duration should be validated according to the configured unit before calculating total training hours.
• This table is commonly used together with trainings and session_access_memberships to build complete training lifecycle reports, including programs, schedules, and employee participation.
• It is one of the primary datasets for training scheduling, execution tracking, and Learning & Development analytics.

Contains information about incidents generated during attendance shifts in Factorial. Each record represents an incidence associated with an attendance shift, including the action performed, time differences, distance information, and the employee and shift affected.

This table allows organisations to analyse attendance exceptions, shift adjustments, modifications, and events related to employee attendance records. It is mainly used for attendance auditing and monitoring changes applied to shift records.

Entity

Attendance / Shift Incidences

Use cases

• Attendance incident reporting
• Shift modification tracking
• Attendance audit analysis
• Clock-in correction monitoring
• Employee attendance exception analysis
• Time difference analysis
• Attendance compliance reporting

Keys

Relationships

• shift_incidences.attendance_shift_id → shifts.idPurpose: Retrieve the attendance shift affected by the incidence and analyse the related attendance record.
• shift_incidences.employee_id → employees.idPurpose: Retrieve employee information associated with the attendance incidence.

Key fields

Features / Relevant data

• shift_action → identifies the type of attendance event or action performed.
• attendance_shift_id → links the incidence with the original attendance shift.
• time_difference → identifies changes or differences caused by the incidence.
• distance → provides location-related distance information when applicable.
• action_time → supports auditing of attendance changes.
• employee_id → enables employee-level attendance incident analysis.

Notes

• Each record represents an attendance incidence linked to an employee shift.
• This table should be combined with shifts to obtain the complete attendance context.
• attendance_shift_id is the primary relationship used to identify the affected shift.
• This dataset is intended for auditing and exception tracking, not official worked time calculations.
• time_difference represents the difference generated by an attendance event and should not be used as official worked time.
• Incidences may represent attendance corrections, modifications, validations, or other shift-related actions depending on company configuration.
• This table is commonly used to investigate attendance discrepancies, monitor corrections, and build attendance audit reports.