> For the complete documentation index, see [llms.txt](https://docs.phocassoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.phocassoftware.com/budgets-and-forecasts/workforce-planning/overview-of-workforce-planning/workforce-planning-foundations.md). # Workforce Planning foundations Understand perpetual plans, temporal cells, and annualized values before you build a workforce plan. ## Perpetual plans Workforce plans can be set up in two ways: * As a **plan for a specific year**, used to forecast or budget through to the end of that year. * As a **perpetual plan**, using [temporal cells](#temporal-cells) to maintain a complete history of workforce changes while avoiding becoming increasingly complex. The benefit of a perpetual plan is that it can be easily re-forecast, rolled into the next budget year, used to build 3- and 5-year budgets, and used to provide multi-year trend data for dashboards and other analysis. By their nature, the employee unique ID, status, and start and end dates aren't temporal. They identify or define the employee's record rather than represent a workforce value that changes over time. All other cells in the plan can change over time. ### Employee unique ID An employee’s **unique ID** is the identifier used for their record in the Workforce database. It must be unique across all workforce plans you publish, not only within the current plan. All workforce plans publish to the same Workforce database. Although each plan publishes to a separate stream, those streams share the same employees, dimensions, and measures. The employee **Name** is linked to the unique ID, not to an individual plan. If you rename an employee in one plan, that name changes everywhere the employee has already been published. {% hint style="warning" %} Don’t use the same unique ID for different employees, even when they are in separate plans, such as salaried-staff and waged-staff plans. When matching IDs are published, Phocas treats them as one employee and combines their records, which can be difficult to reverse. {% endhint %} For guidance on avoiding duplication when you create another plan, see Add employees to a workforce plan > **Unique employee IDs** and Create a workforce plan > **Set up columns within a group**. ## Temporal cells Workforce Planning uses temporal cells, which allow employee information to change over time. Traditional planning tools store one value in each cell. When information changes, such as an employee's salary or department, additional columns or duplicate employee records are often required. {% hint style="info" %} If you're familiar with the [Headcount tab](/budgets-and-forecasts/owner-and-administrator/add-worksheet-tabs/headcount-tab.md) in Budgets & Forecasts, you would have managed such changes using adjustment columns. {% endhint %} Temporal cells solve this problem by storing multiple versions of a value, each with its own effective date. For example, an employee might: * Receive a salary increase on 1 July. * Move to a different department on 1 August. * Increase their FTE on 1 October. Each change is stored against the same employee record. The value displayed depends on the selected As at date. ### As at date The **As at date controls the point in time displayed in the plan**, and, crucially, the effective date of any changes you make. When you move the date forwards or backwards, the grid automatically updates to show the values that were effective on that date. For the above example: * Viewing the plan as at 1 July displays the new salary after the pay increase takes effect. * Viewing the plan as at 1 August displays the employee in their new department. * Viewing the plan as at 1 October displays the new FTE value. The **As at date also drives the effective date of any changes you make**. Any temporal value you enter in the grid (or import from a file) while an As at date is set takes that date as its effective date. Set the As at date to when a change should apply, then enter, paste, or import the new value. See Use the As at date and Edit in bulk directly in the grid. The temporal values are used in the published stream, therefore, the published stream reflects the salary increase, transfer or working hours increase from the relevant effective dates. {% hint style="warning" %} You can't set an effective date earlier than an employee's start date. To correct the value that applied from their start date, update that timeline entry directly instead of trying to backdate a change. See Use Manage timeline. {% endhint %} ### Timeline, cell history, and audit log Three related tools let you add, review, and audit the changes made to temporal cells over time. * **Manage timeline**: Directly add, edit, or delete effective-dated changes for a cell. * **Cell history**: View a record of every change made to a cell. * **Audit log**: View changes across *all* cells in the plan. ### Temporal dimensions Temporal cells are not limited to remuneration values. Most employee attributes can change over time, including dimensions such as department, location, and role. For example, when an employee transfers to another department, you simply update the department value from the effective date of the transfer. You don't need to create a second employee record or end-date the original record. ## Annualized values and spreading You enter measure values in a workforce plan as annualized values. For example, an annual salary of $80,000 rather than a monthly or per-pay-period amount. When you publish the plan, the tool spreads these annualized values into daily transactions in the Flex Modes database. {% hint style="info" %} Currently, all measure values must be entered on an annualized basis. Future releases will support additional value aggregations and spread methods. {% endhint %} For each measure, you choose how the annualized value is distributed across the publish period: * **Monthly**: The annual value is divided by 12, so each month contains the same total. Individual daily amounts vary based on the length of the month (a day in February has a slightly higher value than a day in January). * **Daily**: The annual value is divided by the number of days in the year, so each day has the same amount. Monthly totals vary based on the length of each month. * **Yearly**: The entire annual value is placed on a single day you choose within the year, rather than being divided across days or months. Use this for values that are paid once a year, such as an annual bonus. See Change the spread method for how to change the spread for a column. If an annualized value changes at a point in time (for example, a mid-month pay rise), use a [temporal cell](#temporal-cells) to record the new value from its effective date. Because published transactions are written daily, effective-dated changes are accurate to the day. The new value appears in the Flex Modes database from the exact date it takes effect, regardless of the spread method. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.phocassoftware.com/budgets-and-forecasts/workforce-planning/overview-of-workforce-planning/workforce-planning-foundations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.