Plan resources and capacity

Plan a commitment without inventing actual work#

Use Resource Planning in the correct corporate workspace to declare availability for people, rooms and equipment. Prepare a project allocation, review its exact resource and UTC interval, then confirm it deliberately. A draft is tentative and reserves no capacity.

The capacity board includes every retained confirmed/completed commitment, including projects you cannot read. Its opaque busy windows reveal capacity consumption, not private allocation titles, project/customer identities, planning notes or source events. An empty authorized allocation list does not mean a resource is free.

Completion acknowledges an ended planning block. It never creates actual worked time, attendance, Timesheets, payroll, wages, billing or proof of delivery. The first release is planned-only; recorded actuals need a separately verified scoped integration.

Install the project context before planning its resources#

Install and configure Projects first. Its existing To Do prerequisite continues to own canonical tasks. Resource Planning does not create another task copy or silently install dependencies. Review the current package’s app allowance and any separately priced add-on before enabling the app.

This app belongs to a corporate workspace. A person resource maps to one existing current working staff member; it does not invite or create an account, transfer a personal profile or bypass the package’s staff limit. Rooms/equipment are record-only resources.

Current membership, workspace expiry, module/prerequisite licences, subscription allowances and role ceilings are checked again on writes. A retained future commitment cannot be silently orphaned by removing its person/planner or an essential prerequisite. Resolve the commitment with an authorized planner before the incompatible change.

Official references: App prerequisites and installation ↗ · Plan work and deliver projects ↗

Choose writing scope, planners and resource managers deliberately#

The workspace owner or administrator configures the board’s IANA timezone, app writing scope, project planner mode and additional resource managers. Setup is versioned and records an actor-scoped request and immutable policy history. An exact retry does not create another policy version; a changed or stale policy must be reviewed again.

The default board timezone interprets the horizon dates. Each operational resource has its own explicit local calendar and timezone. Changing the setup default does not rewrite an allocation’s UTC interval or its original confirmed resource/calendar snapshot.

Review operational resource visibility, private project allocation scope and the separate scheduling-note boundary. Confirm the local-calendar purpose; no workweek, holiday calendar, statutory hours or overtime rule is assumed from a business country, currency or language.

Keep operational capacity and private project content separate#

Current app readers may view operational resource metadata and complete opaque busy capacity. Allocation details and source events require current reading access to their project. Current project planners act only within the configured planning mode, Projects access and current app writing ceiling.

Workspace owners/administrators configure the app and ordinarily manage resources. Additional resource managers are explicitly named. They may need operational staff names to map an existing person resource, but that does not grant a project’s private content. Read-only users remain read only.

A person assignment additionally needs current eligible project contribution for the mapped member. Selecting a resource never grants that person project membership. A resource manager who cannot read a conflicting private project receives a generic coordination explanation rather than its title, customer, notes or allocation ID.

Private exception notes have their own permission boundary: current authorized resource managers or the mapped person may read them. Reading a permitted retained note is distinct from permission to edit availability. Old browser tabs, direct requests and exact retries recheck current scope.

Create a resource without changing its retained identity#

Choose Person, Room or Equipment, then enter a permanent code, an operational name, the explicit IANA timezone and concurrent capacity. A person maps to one existing eligible staff account and has capacity one. Rooms/equipment permit one to one hundred concurrent units under your declared operating model.

After creation, the resource kind, code and mapped person remain immutable. Use another resource for a different identity. Names and operational descriptions may change through current versioned resource management; keep private project context and unrelated sensitive information out of broadly readable metadata.

Deactivate a mapped person resource before removing or demoting that person’s working workspace membership, even when no future allocations exist. If future commitments remain, coordinate their explicit cancellation or replacement first; an active former-staff resource must not appear as usable free capacity.

An inactive resource remains in history and cannot receive new planning. Deactivating it or reducing its capacity/calendar does not erase future or ongoing confirmed commitments. Current staff/prerequisite changes likewise cannot silently release retained work. Review the retained source before changing identity, availability or membership.

Declare local windows instead of assuming a standard workweek#

A weekly resource calendar uses explicit ISO Monday–Sunday local windows. An empty day is deliberately closed. Declare up to four nonoverlapping windows per day; a closing time may be 24:00. A window must finish after its start, and an overnight pattern must be split across the two days.

No national or religious workweek is applied automatically. Add the days and windows that actually describe your resource’s availability. If you copy one reviewed day to other selected days, those days’ existing windows are replaced. Copying an empty day closes them; review the complete result before saving.

The server converts local availability into actual UTC windows under the resource timezone. Clock changes can create gaps or repeated periods; a local day is not assumed to be exactly twenty-four hours. Availability must cover every actual minute of a confirmed allocation.

Current calendar totals describe the current declared calendar over the selected horizon. They do not rewrite earlier confirmed calendar snapshots. Past commitments can remain visible outside a later current calendar; review their original source rather than interpreting the display as new actual time.

Replace one literal local date without erasing its history#

An active date exception replaces the weekly windows for its literal local date. It does not add another window to that day. An active exception with no windows closes the date. A disabled exception restores the weekly rule only when retained future commitments remain compatible.

The original exception date is immutable. Deactivate the old date and prepare the other date when the intended day changes. Review the resource timezone and horizon before saving; an exception outside the displayed horizon will appear when that date range is selected.

Private scheduling notes are separate from the operational availability windows and their events. Keep the current note, replace it, or clear its current body deliberately. Omitting the note preserves the preceding revision; explicit clearing does not remove protected retained history. Do not add unrelated sensitive personal information.

Count a private commitment without disclosing its project#

The resource board and availability preview deliberately include all retained confirmed/completed load for the resource. Busy UTC windows and units are opaque operational facts. They do not expose allocation/project/customer identifiers, titles, planning notes, rates or private exception-note bodies.

Project allocations and their events follow current project reading. Workspace administration, resource management or an empty filtered source list is not a reason to ignore private commitments. Removing someone’s project access does not silently make their retained reservation disappear.

Use restricted allocation notes for project work context and the separate permitted exception-note control for necessary scheduling context. A broad operational resource description is not a private note. Keep each profile’s staff, licences and business records in its intended workspace.

Use exact UTC minutes and a deliberately chosen local clock occurrence#

Horizon From is inclusive and Until is exclusive, interpreted in the board’s declared IANA timezone. Resource windows and exceptions use each resource’s own timezone. An allocation is an exact UTC start/end interval, not a literal calendar date or an inferred workday.

Allocation forms use whole local minutes in the selected resource timezone. A nonexistent local clock time must be corrected. If a clock time repeats, deliberately choose the intended occurrence/UTC offset. A changed resource zone requires a fresh review of the visible local input and exact UTC preview.

The interval must be positive, no longer than twenty-four actual hours, and within the supported 2000–2100 date range. Seconds are not silently rounded. For a longer plan, prepare separate justified intervals.

Confirmed source facts retain the exact UTC instants plus the resource/calendar snapshot and its IANA zone name. This release does not store original start/end UTC-offset fields or a frozen timezone-rules database. A later local-clock rendering is not a claim of an originally captured offset; the retained UTC instants remain authoritative.

Prepare a tentative project plan before reserving capacity#

Choose a currently plannable project and active resource. Review a person’s current eligible contribution to that project, the resource’s immutable code and timezone, an internal title/context, exact UTC interval and concurrent units. The title and notes follow project scope rather than appearing in opaque busy capacity.

Saving creates or revises a tentative draft. Drafts consume no capacity, do not guarantee a later reservation and do not create actual time, a task completion, a customer invoice or inventory movement. Project/resource identity stays fixed after the draft is created.

Only permitted planners may revise draft facts. Confirmed/completed intervals cannot be edited into another reservation. An inactive resource or changed role/source can prevent a draft from progressing; retain the original and prepare a permitted separate plan when necessary.

Confirm the exact current plan as a separate decision#

Open the draft and review its resource, project context, exact UTC interval, units and current capacity during that actual interval. The preview includes all retained commitments; an already confirmed allocation is itself included in current busy load.

Confirm with a concrete retained reason and acknowledgement. The server rechecks current role, project/person eligibility, active resource, availability and pointwise concurrent capacity under shared locks. Another operator may reserve capacity after the preview; a draft is not a hold.

A successful confirmation retains the original planned facts and relevant resource/date-calendar snapshot. A repeated exact request reauthorizes and does not duplicate the decision. Confirmation establishes a planned commitment, not attendance, actual time, legal working-time compliance or proof of delivery.

Resolve the commitment rather than bypassing private capacity#

Capacity is checked at each interval boundary. Two commitments that overlap your proposed span but occupy different portions must not be naively added as if simultaneous. The server evaluates all actual pointwise units and every minute’s declared availability.

A private project or closed source can still hold retained capacity. If the source is unreadable, the explanation stays generic. Coordinate with an authorized planner or resource manager; an administrator does not automatically receive private project content through a conflict.

Calendar/timezone/capacity reductions, resource deactivation, relevant staff removal and incompatible prerequisite/planner changes are rejected when a future or ongoing confirmed commitment would be orphaned. Review or explicitly cancel the affected source under current authority before the configuration change.

A rejected confirmation or stale version does not create an allocation or silently discard entered data. Keep the draft, inspect the current source and review the new facts before retrying. Do not assume that a browser refresh or copied request restores a removed permission.

Cancel deliberately and prepare a separate replacement#

Revise a draft while it remains tentative. To change confirmed project/resource/interval facts, retain a cancellation reason, explicitly cancel the current planned commitment and prepare a separate permitted draft. The original source, captured calendar and decisions remain.

Cancellation releases that reservation; it does not delete its history or imply that work never happened. A new draft must pass current person/project, availability and pointwise capacity checks. A replacement is not automatically guaranteed the capacity just released.

The first workflow does not silently clone private notes to another project, link external calendar invitations, manufacture actuals or assert a structured commercial replacement. Record any necessary handover/reference deliberately within its permitted project context.

Acknowledge an ended plan without manufacturing actuals#

Only an ended confirmed block can receive a planning-completion acknowledgement. The server’s current time and current planner authority govern the action. Record a concrete reason and review the exact source before confirming.

Completed planning keeps the captured original interval, units and resource/calendar facts. It remains historical planned load. It does not prove attendance, a statutory break, actual productive hours, delivered work, payroll, wages, a Timesheets entry or customer acceptance.

Use the separate actual-work, delivery and financial workflows for their respective facts. This release has no verified actuals adapter, so the resource board does not invent an actual-versus-plan comparison.

Read the denominator before comparing open, committed and free#

Open capacity is actual open-window duration multiplied by the resource’s concurrent units. A room declared with two units and four open hours has eight capacity-hours. A one-unit two-hour allocation inside those windows commits two capacity-hours, leaving six within that declared open period.

Committed capacity includes retained confirmed/completed intervals within the exact horizon. Free capacity is the remaining capacity inside current open windows; it is not simply a claim that every unlisted project is free. Current calendar changes can leave historical load outside current open windows, which is flagged for review.

The visual track summarizes the exact horizon, not a fixed twenty-four-hour-per-day attendance grid. Every supplied opaque busy interval contributes; exact totals remain visible. Board totals are per resource and the shown resource page, not an invented workspace-wide sum across hidden pages.

Capacity units, planned elapsed duration, approved recorded time and customer money are separate. A completed plan does not add actual hours, and a current denominator does not rewrite an original confirmed calendar.

Keep current calendars, captured source and bounded exports distinct#

Each resource/calendar/allocation change has a current version, actor-scoped request and retained event. Setup records its own policy versions. Exact retries reauthorize and avoid duplicated source history. A stale or reused request for different data is rejected rather than silently overwriting the current record.

Confirmed allocations display their original resource/calendar snapshot separately from current resource availability. Resource history is operational; allocation history follows current project scope. Private exception-note bodies are not added to broad operational events or opaque load.

The board uses at most twenty resources per page; allocation lists use fifty. Selectors page fifty stable name-plus-ID choices and independently retain authorized selected IDs. Source event views are bounded, with up to one hundred allocation events and fifty operational resource/calendar events shown. Setup policy history is paginated.

The horizon is at most thirty-one actual days; date-exception reads are bounded. Print labels the resource/allocation result pages and exact horizon. Allocation-list CSV uses its matching authorized filters and at most one thousand rows; a board export is labelled as all authorized allocations in its horizon. Exports neutralize spreadsheet-formula-leading text and materialize permitted values before request scope is cleared.

On the capacity board or allocation list, set the horizon, filters and result page, then choose Print these authorized result pages. Select Document design to preview Classic or one of 15 additional layouts. Choose Print or save PDF and select a printer or your browser’s Save as PDF destination.

Printing or exporting a visible source list does not reveal the private projects behind opaque busy capacity. Retain records under the organization’s appropriate purpose/access/retention policy. The disposable demo is not a statutory archive.

Review the business jurisdiction without assuming legal hours#

The corporate business country, resource timezone, local availability, language and currency serve different purposes. A resource in another timezone does not change the organization’s jurisdiction or establish employment, tax, payroll, holiday, rest, overtime or privacy compliance.

Deliberately review local operating calendars, the scheduling purpose, staff access and appropriate recordkeeping with competent local advice where needed. This planned-only app applies no country-presumed workweek, statutory break deduction, overtime formula or government registration.

Existing ZATCA, FBR, ATO and other authority integration boundaries remain separate. Resource Planning does not certify an account, send regulatory submissions or make the platform approved for a jurisdiction. Market only the tested planning capabilities and the integrations that have separately completed their actual release requirements.

Official references: Business country, recordkeeping and tax review ↗ · Record actual time and bill reviewed work separately ↗

Keep entered plans and resolve the current source safely#

For a stale version or conflicting configuration, keep the entered local draft and compare it with the current source. Saving a different source/version must not erase a newer operator’s facts. Refresh deliberately only after preserving and reviewing the intended changes.

If a person leaves, a planner loses scope, a project closes or a resource calendar needs reduction, do not try to bypass retained commitments. An eligible current owner/manager may retain the permitted cancellation path for closed projects below current app ceilings. Resolve or coordinate the commitment before removing its essential context.

If the board is busy but your allocation list is empty, review the exact horizon, current calendar and opaque capacity explanation. Ask the appropriate authorized planner to review their source; do not infer a private project name or treat hidden load as free.

Demo workspaces expire and are cleaned under their configured lifetime. Do not use the demo to keep business evidence, and do not interpret a successful disposable action as a provider connection, legal approval or production promotion.