Business rules guide

The rules Consult applies on its own, and the fields and settings that change how it behaves.

Consult applies a number of rules without anyone asking it to. Some run on a schedule, such as the nightly leave checks and the weekly rollover of unused hours. Others are triggered by something a user does, such as saving a timesheet or approving an allocation. A third group is driven by configuration, where a field on a profile, a project, or an organisation setting quietly changes what happens somewhere else.

This page describes what Consult does, when it does it, and which field or setting controls it. It covers behaviour rather than instructions, so each section links the rule back to the place the value is set. For the wording and delivery of the messages these rules send, see the notification catalogue.

Scheduled activity

The following runs automatically, without anyone triggering it.

Users and profiles

Working hours

Consult needs to know how many hours a person is expected to work in a day. The organisation-wide figure is set under Settings > Configuration, and an individual user profile can override it. Where a user has their own value, it replaces the organisation default for that person.

That single figure reaches further than the profile page. It determines:

• The hours the user is expected to capture on their timesheet each week.
• The utilisation and compliance percentages shown for that user.
• The hours credited when a public holiday falls in the week.
• The capacity used when checking whether the user is available to take on more work.

Changing the organisation-wide figure also rewrites the hours recorded against every leave day from today onwards. Leave that has already been taken is left as it was.

Contractors

A contractor with no required daily hours is treated as having no expected capacity. They can be allocated to work without triggering the approval that would normally follow from exceeding expected hours, and no expected weekly hours are calculated for them. The maximum weekly hours limit still applies to them in full.

Reporting lines

The reporting line on a user profile decides who approves that person’s leave, allocations and timesheets. Where every one of a person’s managers is unavailable, approvals escalate one level further up the same line.

Deactivating a user removes them as a manager from everyone who reported to them, so those approvals move elsewhere immediately. A deactivated user can no longer sign in and disappears from the user list, but remains visible in organograms and manager listings for two months afterwards.

New accounts

Creating a user sets up their leave balances from the leave settings for their country, sends them a welcome email with a link to set a password, and notifies the administrators. Changing a user’s email address clears their verification, so the address has to be confirmed again.

Internal rates

The internal rate on a user profile is what Consult costs their time at, and is the basis of margin reporting. Adding a new rate closes the previous one the day before the new rate starts, and reprices every scheduled week from that date onwards. Weeks before it keep the rate they were costed at.

Where the user’s rate is held in a different currency from the project, it is converted into the project currency at the recorded exchange rate.

Projects

Project codes and defaults

A project created without a code is given one automatically, built from the client’s code followed by a four-digit sequence. Where the project has no client, the first two letters of the organisation name are used instead. A code entered by hand is kept exactly as it was typed.

Two further fields are inherited when a project is created:

• Payment terms come from the client, or default to zero days where there is no client. They set the due date on invoices sent to Xero and QuickBooks.
• The business entity defaults to the organisation’s default entity, which determines invoice branding and grouping.

Project status

The status of a project governs much of what can be done with it:

• A project can only be resourced while it is Pipeline, Proposed, Awaiting Order, Sold or In Progress.
• An invoice can only be raised while it is Sold, In Progress or Completed.
• A project can only be deleted while it is Pipeline, Not Won or Cancelled, whatever permissions the user holds.
• Moving a project to Sold captures its current planned hours as the baseline that later changes are measured against.

Project dates

Changing the start or end date rebuilds the schedule around the new period. Weeks that now fall inside it gain schedule entries, and weeks that fall outside it are removed along with any time captured in them.

Two restrictions apply to the dates themselves. The start date cannot be moved past a date on which time has already been captured, and Consult names the person and date that blocks it. Neither date can be changed once the project is Completed, and the start date is additionally locked on Cancelled and Not Won projects.

A week before the end date, the project director is reminded to complete or extend the project. The day after it passes, they are told the project has overrun and that time can no longer be captured against it.

Deferring a project

Deferring a project moves the start date and shifts the end date by the same number of days. Every scheduled week moves with it, so the shape of the plan is preserved rather than rebuilt. The deferral and its reason are recorded in the project activity.

Scheduling and resourcing

How the schedule is built

Adding a resource to a project creates one entry per week of the project period, at zero hours, priced at that resource’s project rate. Projects using a work breakdown structure get an entry per deliverable per week instead. Archived resources get nothing, and weeks that already exist are never duplicated.

Weekly hour limits

The organisation sets a maximum number of hours that may be planned for one person in a single week under Settings > Configuration. Saving the schedule is refused when any week exceeds it. Weeks in the past, archived resources, and entries that are not directly plannable are left out of the check.

Availability

A person is treated as unavailable when, in any future week within the next six months, their planned hours plus their leave plus the hours being requested would take them past the weekly maximum. Being unavailable blocks allocation approval and raises a conflict warning on the request.

The same test applies in reverse when leave is requested. A leave request that would make someone unavailable on a project they are already committed to is refused, and the affected projects are named.

Allocation approval

Every week of a proposed allocation is judged against two thresholds, and the worst week decides the outcome for the whole allocation. The three possible outcomes are:

• Within expected: the planned hours sit inside the person’s expected working hours.
• Above expected: the planned hours exceed their expected hours but stay inside the weekly maximum.
• Above maximum: the planned hours exceed the weekly maximum once public holidays and approved leave have been taken off.

An allocation is approved on the spot when every week is within expected and the person making the allocation already manages the resource. Anything else raises an allocation request for the resource’s manager to decide.

A request still pending after seven days gains an additional approver, the manager’s own manager. Where the organisation has set a number of days for automatic approval under Settings > Configuration, requests older than that are approved without anyone acting, provided every week is still within expected and the person is still available. Leaving that value at zero switches automatic approval off.

Changes that need approval again

Raising planned hours in the current week or any week after it withdraws the existing approval and raises a fresh request. The previously approved hours are kept so that they can be put back.

Rejecting the request restores the last approved plan. Where the resource had never been approved in the first place, rejection removes them from the project instead. Lowering hours, and changing hours in weeks that have already passed, never triggers approval.

Rolling unused hours forward

Where rollover is enabled on a project, Consult compares planned against actual hours each week. A shortfall is pushed into the following three weeks, filling each one up to the weekly maximum less whatever is already planned there and any leave. Where the shortfall does not fit inside that window, nothing is moved at all and the project manager is told the rollover failed. A week is only ever rolled over once.

Aligning forecast to actuals

Aligning the forecast overwrites planned hours with actual hours for weeks that have already passed. The current week and every future week are left alone. Because past weeks never trigger approval, aligning the forecast raises no allocation requests.

Rates on the schedule

Every scheduled week carries its own rate, and that rate is what invoices and reports are priced from. Changing a resource’s project rate reprices the current week and the weeks after it, stopping at the first future week whose rate has already been changed by hand. Weeks in the past keep the rate they were planned at.

The discount percentage shown against the resource is recalculated from the agreed rate against the card rate. Each Monday, the rate shown on the resource itself is brought back into line with the rate on the current week, so the header follows the rate timeline.

Archiving a resource

Archiving takes a resource out of planning without erasing their history. Once archived:

• No further schedule entries are created for them.
• They are left out of the baseline, the rollover and the weekly hours check.
• Time can no longer be captured against them.
• Hours already invoiced stay on the invoice, at the rate they were invoiced at.

Spare capacity and over-planning

Spare capacity for a week is the weekly maximum, less everything already planned for that person across all projects, less leave, less public holidays. It never drops below zero, and weeks in the past are not shown. A week is flagged as over-planned when the hours planned across all projects exceed the weekly maximum.

Separately, once a resource’s actual hours reach their planned hours on a project in progress, the project’s managers are notified once.

Timesheets

When time can be captured

Consult runs a series of checks before accepting time against a project, and stops at the first one that fails. Time cannot be captured when:

• The week has already been submitted and has not been rejected.
• The resource has been archived.
• The project manager has already approved that project for the week.
• The hours would take the resource past their total planned hours, where hours management is enabled for them.
• The hours would take a deliverable past its maximum, where that limit is enforced.
• The resource’s allocation has not yet been approved.
• The date falls inside an invoice period that locks timesheets.
• The date falls outside the project’s start and end dates.
• The project is not yet Sold, unless the project allows time to be captured before it is sold.

Expected hours for a week

Expected hours are five working days, reduced by any public holiday that does not fall on a weekend, multiplied by the person’s required daily hours, less any approved leave. The week someone joins is reduced to the days from their start date, and weeks before they joined expect nothing at all. Submitting fewer hours than expected is refused, and both figures are shown so the gap is clear.

Submitting and reopening

A week becomes read-only as soon as it is submitted, and stays that way until a manager rejects or reopens it. Only an approved week can be reopened, which removes the submission entirely and unlocks the week. Where someone is on leave for a full week, Consult submits the timesheet on their behalf on the Thursday and notifies their managers.

Project manager approval

Where both the organisation and the project have project manager approval switched on, submitting a timesheet raises one approval for each billable project the person captured time against. Every project manager on that project is asked to approve, and the resource manager only receives the submission once all of them have.

A rejection by any one project manager rejects the whole week, and their comment is passed on to the employee. The projects that were already approved stay locked, so only the rejected and non-billable projects can be edited again.

Reminders and overdue follow-up

Consult chases outstanding timesheets in stages. The stages are:

• A reminder every Friday afternoon to anyone with an active project and no submission for the week.
• A reminder on any weekday to anyone whose leave starts tomorrow and runs to the end of the week.
• An overdue notice a configured number of days after the week ends, sent once for each outstanding week.
• An escalation to the person’s managers a further configured number of days later, sent once for each outstanding week.

Overdue notices and escalations are only sent when timesheet submission is switched on and the relevant number of days is set above zero under Settings > Configuration. Escalation cannot be enabled unless overdue notices are. Where a manager is on approved leave on the day an escalation is due, it goes to their own managers instead.

Compliance figures

Where timesheet submission is switched on, organisation compliance is the share of active users who submitted. Where it is switched off, it is the share of users who captured at least their expected hours, averaged across the weeks in the period.

The utilisation report shows a monthly percentage for each person, capped at 100, built from their captured hours against their required daily hours across the weeks they were employed. Months made up entirely of weeks before someone joined show as not applicable rather than zero.

How actual hours are totalled

Saving a timesheet re-totals actual hours onto the scheduled week, and then onto the deliverable, the resource and the project in turn. Where actual hours arrive through a schedule import rather than daily capture, the difference is spread across the weekdays of that week, whole hours first with any fraction on the last day. Weekends never receive hours.

Leave

How leave days are counted

Weekends and public holidays inside the requested period are skipped, so they produce no leave day and consume no balance. Half days are supported, and the duration of the request is the sum of the day values rather than a count of dates. The hours recorded against each leave day are the day value multiplied by the organisation’s required daily hours, which is what removes that capacity from the schedule.

Rules when requesting leave

Three conditions have to hold before a request is accepted:

• The first and last day must both be working days, so a request cannot open or close on a weekend or public holiday.
• The dates must not overlap leave the person already has.
• The leave must not make the person unavailable on a project they are already committed to.

Approvers and reminders

The person’s managers are attached as approvers when the request is created. Where every one of them is on leave that day, their own managers are added alongside them.

A request still awaiting a decision is reminded five days before it starts, and again as the start date approaches. A request that is still pending ten days after it was submitted, and whose start date is already three or more days in the past, is declined automatically. Sick leave and family responsibility leave are never declined this way.

Balances

Balances move on approval rather than on request. Approving a request deducts its duration from the matching balance, and annual leave deducts from both the available balance and the portion of the actual balance falling in the current month. Every movement is recorded against the balance so it can be traced later.

Cancelling an approved request returns the balance and releases the days. Declining a request releases the days without any balance movement, because nothing had been deducted yet.

Balances themselves are topped up in two ways, set per country and leave type under Settings > Leave:

• Monthly accrual adds a fixed amount each month, and never takes the balance past its maximum.
• Fixed cycles add an allocation when the previous cycle expires, discarding whatever was unused if the leave type is configured that way.

Approved annual leave in the future is drawn down month by month, so the actual balance reflects leave that has been committed rather than only leave already taken. Changing a leave setting creates the matching balance for users in that country who do not have one yet, reduced by the leave of that type they have already taken in the current cycle.

Contractor unavailability

A contractor marking themselves unavailable creates an approved record immediately, with no approver and no approval notification. The days block their availability in exactly the same way as leave, and the type does not appear in the ordinary leave application form.

Deleting a leave request

An approved request can be deleted by the person it belongs to while it is still in the future, and by an approver for up to thirty days after it ends. Cancelled and declined requests cannot be deleted at all.

Expenses

Creating an expense report

Every report is given a reference number automatically, and it cannot be edited. Where the report is linked to a project it takes that project’s currency, and the currency determines the tax percentage used for VAT. The total is re-calculated from the expenses and mileage claims on the report every time one of them changes.

VAT and mileage

VAT is never entered directly. On an expense marked as VAT inclusive, Consult works the VAT back out of the amount using the currency’s tax percentage, and derives the amount excluding VAT from it.

Mileage works the same way. The amount is calculated from the distance and the rate rather than typed, and marking a claim as a return trip creates a second claim with the locations reversed at the same rate.

Submitting and approving

A report can only be submitted while it is still a draft and has at least one expense or mileage claim on it.

Who it goes to depends on the project. Where the report is linked to a project with a director, the director is the approver. Where it is not, it goes to the submitter’s manager. An approver has to be able to see the project’s financials, and cannot approve their own report unless they are the project director.

A report containing a training expense is routed to the training recipients set under Settings > Approval notifications, rather than the general expense recipients.

Reopening and deleting

Reopening a report clears the whole approval trail, so the submitted, checked, approved and rejected stamps are all removed and the report returns to draft. Deleting a report deletes its expenses and mileage claims with it, along with any attachments held against them.

Attaching expenses to an invoice

Only reports that are approved, billable and not already invoiced can be attached to an invoice. Attaching or detaching one re-calculates the invoice total straight away.

Invoicing and rates

When an invoice can be raised

An invoice can only be created on a project that is Sold, In Progress or Completed. Its period must sit inside the project’s start and end dates, and must not overlap the period of another invoice on the same project.

What an invoice contains

Raising an invoice copies the hours captured in the period onto it, along with the rate that applied to each of those weeks. Both are frozen at that point, so changing a rate afterwards never reprices an invoice that already exists. Changing the invoice period rebuilds the figures against the new dates.

The total is the frozen hours at their frozen rates, plus any attached expense reports at their amount excluding VAT, plus any line items added by hand. The invoice number is the project code followed by the invoice’s own number, and the due date is the invoice date plus the project’s payment terms.

Locking timesheets

An invoice can be set to lock timesheets for its period, which prevents anyone capturing or changing time against those dates. Invoices left unlocked place no restriction on capture.

Deleting an invoice

Deleting an invoice releases any expense reports attached to it, so they become available to invoice again. Invoiced hours are re-totalled across the project, so the figures on the schedule and on each resource fall back in line.

Currencies and exchange rates

One currency is the organisation’s base currency, and setting a new one clears the flag from the previous. Consult records the exchange rate of every other currency against the base once a day, which is what gives historical conversions a rate appropriate to their date. A conversion uses the most recent recorded rate, and falls back to the rate configured on the currency where no history exists.

Adding a currency creates a recommended rate for every designation, converted from the existing rates. Those rates can be adjusted afterwards per designation.

Permissions and approvals

Roles and abilities

A role grants a set of abilities, and a role holding the wildcard ability is granted everything. Abilities are checked before any other rule, so a user who holds the matching ability passes straight through.

Permission to manage projects grants every action on a project, including viewing its financials. The one exception is deletion, which still depends on the project’s status.

Financial visibility

Beyond the administrators, a project’s financial figures are visible to the project director, an account lead on the client, the project’s financial administrator, and any project manager who has been granted the ability on that project. The same test decides who is allowed to approve expense reports linked to the project.

Who can approve what

Approval rights are held by the person named on the request, not by seniority alone:

• Allocation requests are approved by the approvers on the request, or by anyone who manages the allocated person. Permission to manage projects does not confer this.
• Leave requests are approved by the approvers attached to the request. Permission to manage users confers everything else on a leave request, but not the right to delete one outside the normal window.
• Timesheets are approved by the project managers first, where project manager approval is enabled, and then by the resource manager.

An allocation cannot be approved while the person is still unavailable, so the conflict has to be resolved first.

The inbox

The inbox count is the total of everything waiting on that user: leave requests, timesheet submissions, project manager approvals, allocation requests and expense reports. Each contributes according to its own approval rules, so two people looking at the same records will see different counts.

Analytics access

The analytics sections are shown according to what the user is responsible for. Resource analytics requires having at least one direct report, project analytics requires permission to manage projects, and financial analytics requires permission to view internal rates. Opening analytics without specifying a section lands on the first section the user is allowed to see.

Settings that change how Consult behaves

These are set once for the organisation under Settings > Configuration.

Recipient lists for approved expenses, approved training and approved leave are set separately under Settings > Approval notifications, and leave accrual is set per country and leave type under Settings > Leave.

Fields that change how Consult behaves

These are set on an individual record, and each one changes behaviour somewhere else.

Designations matter too. A resource whose designation identifies them as the project director is set as the project’s director, which moves expense approvals and financial visibility with it.