How AuditSchedule works, feature by feature. This is the same reference available inside the app, published here so you can read it before you sign in.
AuditSchedule is a tenant-specific planning workspace for internal audit teams. It combines people, projects, allocations, leave, holidays, travel, events, conflicts, approvals, analytics, capabilities, permissions, settings, and billing into one live scheduling system.
Both onboarding steps carry a support link, and it becomes more prominent when an error is showing. If the account step reports a problem, check the wording first: an invalid password, an email that already has an account, an address that was never confirmed, or unaccepted terms are all fixable on the spot, and a confirmation email that has not arrived can be re-sent from the same screen, in either sign-up or sign-in mode. Re-sending never changes the password on a pending account, so if someone else has tried to sign up with your address, the password you chose is still the one that works. If we say we can no longer deliver to your address, that one will not work no matter how often you retry: sign up with a different address or write to support@auditschedule.com. If workspace creation fails, the message may include a reference code. Email support@auditschedule.com using the link on the page, which prefills the workspace URL you tried, the reference, and the time, and we can create the workspace for you.
The link opens a page with a single Confirm my email address button, and pressing it is what actually confirms you. That extra press is deliberate. The link works only once, and many corporate mail systems open every link in an incoming message to scan it, which would use your link up before you ever clicked. Waiting for a real press is what keeps the link yours. Once you press it you go straight on to workspace setup. If confirmation fails because of a connection problem, a temporary service failure, or too many requests, wait a moment and press the same button again; you do not need another email. If the page says the link is invalid or has expired, request a new one.
Yes. The availability check stops waiting after ten seconds and shows "Could not check availability. You can still continue." Enter a workspace name and valid URL, accept the terms, and press Create workspace. The server checks the URL again when creating the workspace and reports if it is already taken. If it says the workspace is still being set up, that is your own create still finishing: wait a moment and press Create workspace again, and do not change the URL. If the workspace was created but your session could not be activated, sign in again to continue. If we cannot confirm whether setup completed, try signing in; if you still cannot access the workspace, contact support with the reference shown on the page.
Check whether you ever confirmed your address. An account that was created but never confirmed cannot sign in, and that is a separate thing from a wrong password. Sign-in now says so directly: on the sign-up page it offers a Resend confirmation email button in the same message, and on the login page it links you to the page that can send one. Press it, open the link, press Confirm my email address, and sign in as normal. Re-sending does not change the password on a pending account, so the one you first chose is still the one that works. If the message says your email or password is wrong instead, that is what it means: use Forgot your password to reset it.
You can. Signing in with an email and password takes you back to workspace setup, and so does Continue with Google. Google used to sign you back out at that point and ask you to accept the terms again, which was wrong when you had already accepted them; it now recognises the acceptance already on record and returns you to the setup step you left. Fill in the workspace name, URL and work week and you are through. If you are genuinely being asked to accept the terms, it is because we hold no acceptance for your address, and ticking the box is what records it.
Google does not tell us whether your address already has an account, so the button creates one when there is not, and we cannot accept a new account without a recorded acceptance. Ticking the box costs you nothing if the account already exists, and it is what stops a first-time Google sign-in from being turned away after the fact. Signing in with an email and password does not ask, because it only ever reaches an account that already exists.
Use the left navigation. Your visible menu is permission-based, so it only shows modules your organization role can view. The main modules are Grid, Overview, Events, Dashboard, Approvals, Conflicts, Travel, Leave, Capabilities, Manage, and Settings.
Access is controlled by base role and named organization role permissions. A module can be view-only, editable, or hidden. Some modules can also be scoped to All, Team, or Own records, which limits what a linked user can see or change. Admin-level users normally have broad access; custom roles can grant or remove view and modify rights per module.
Billing now lives inside Settings as a Billing tab. Users with billing permission also see a lower-left billing status row. If billing becomes overdue or blocked, the workspace directs users to Settings so billing can be fixed.
Yes. The Guided Tour link in the sidebar opens a setup checklist that walks you through getting a workspace running in five steps: upload people, upload projects, bulk allocate, fine-tune allocations on the grid, and grant access. Projects unlock once people exist, and the two allocation steps once projects exist; granting access is open from the start so you can invite a colleague to help with setup. Each step tracks live progress from your real data (for example how many people or allocations exist) so you can see how many steps are complete. An "Explore further" section adds optional tours for customizing your workspace in Settings, Events, Travel, Leave, Capabilities, Approvals, Conflicts, and Dashboard.
Yes. In a workspace with no active people and no projects, users who can edit in Manage see "Load sample data" on the Guided Tour: eight sample people, six projects marked "(sample)", and several months of allocations starting two months ago, including one over-allocation so the Conflicts page has something to show. While it is loaded, a "Remove sample data" button appears on the Guided Tour and at the top of Settings (Settings stays reachable even when an ended trial has paused the workspace). Removing deletes exactly the people and projects that were loaded (with their allocations) and also removes a sample person or project you edited. Anything you added yourself stays; if it named a sample person as director, team manager or line manager, or a trip was linked to a sample project, it keeps its place with that field cleared. Sample data cannot be loaded once billing has been set up (a checkout started or a subscription created), and a subscription cannot be started until the sample data is removed, so you are only billed for your real team. Under a plan lock, loading is refused for anyone the lock applies to if a locked period that ticks Projects covers the months the sample is loaded into, and removal is refused for them if it would remove or change anything the lock covers, such as the leave of a sample person inside a locked period or a locked project that a sample person is director of. The lock does not hold back administrators or the roles that keep access, though they still need edit access to Manage, and the other conditions above still apply.
When a workspace is created, its owner gets a welcome email with the workspace address, the trial end date, the three steps to a working plan (add people, add projects, allocate) and a link to the Guided Tour. If the workspace still has no active people 3 days after signup, its admins get one reminder to add their team (sent once, and not after the first 14 days). Trial reminders are covered under Billing. Replies to these emails go to support.
Yes. Each account can own one workspace of its own, and being a member of other people's workspaces does not count against that. If you open Start free trial while signed in, you are asked whether to open the workspace you already belong to or create your own, which gets its own free trial. Your access to the other workspace stays as it is. Once you belong to more than one workspace, signing in asks which one to open. If you already own a workspace, Start free trial takes you straight back to it instead.
The Plan Grid shows "Your plan is empty" while the workspace has no people at all (a workspace whose people are all inactive still shows the grid, where Show inactive reveals them). Users who can edit in Manage get buttons to open the Guided Tour or go straight to adding people; everyone else sees a note that the workspace admins have not added anyone yet. The grid appears as soon as the first person is added.
Each Guided Tour step links into the relevant page and starts a short tooltip walkthrough that highlights the key controls in place: where to upload people, how the five Bulk Allocate steps work, or how to edit dropdown options and color defaults in Settings. Use Back, Next, and Done to move through a walkthrough, or close it at any time. They are launched from the Guided Tour rather than shown automatically on every visit.
Yes. A round help button with a robot-reading-a-book icon sits in the bottom-right corner of every workspace page. Open it to ask questions about how AuditSchedule works in plain language; it is an AI assistant that answers from this manual and, when relevant, offers a button to jump straight to the right page. Because it relies on your own role, it explains where a feature lives rather than promising you can access it, and it does not change any of your data. If it cannot answer something, it points you to the Feedback button or a workspace administrator.
Use the Feedback button at the bottom of the left sidebar. It opens a short form for sharing suggestions, questions, or issues with the team. It is available to every signed-in user regardless of role. After sending, you can track your feedback on the Feedback tab of My Profile, where each item shows its current status and any reply from the team.
Yes. Open My Profile (click your name near the bottom of the sidebar) and select the Feedback tab. It lists every rating and message you have sent, each with a status badge (New, Planned, Done, or Won’t fix) and, when the team has replied, their response shown beneath your message. Use the All, Unresolved, and Resolved buttons to filter the list; Resolved covers items marked Done or Won’t fix, and Unresolved covers items still New or Planned. You can link straight to it at /profile?tab=feedback.
Yes. On a phone the sidebar opens from the Menu button, and a tab bar along the bottom of the screen holds the Plan Grid, Leave and Approvals (with its count of requests waiting). If you cannot see one of those pages, Travel, Overview or Events takes its place. List pages such as Leave, Travel, Approvals, Conflicts, Capabilities and Manage show each record as a card; tap a column name at the top of the list to sort by it. On the Plan Grid, the layer toggles and filters sit behind the Filters button at the top, which shows how many of them are hiding something from the view; tap Hide filters to close them again. Select and Legend stay beside it. On Manage, choose a section from the dropdown at the top. On Overview and Events, tap a bar or an event to see its details at the bottom of the screen, and tap anywhere else to close them. Building a plan is easier on a larger screen, but everything works on a phone.
Click your name near the bottom of the sidebar to open My Profile. It shows your person card (team, role, location, access role, and active status), your current, upcoming, and past projects and events, your recorded skills and certifications, summary stats (projects, man-weeks, leave days, holidays, and travel trips) for a date range you choose. A separate Feedback tab lists the feedback you have sent with its status and any reply from the team. If your account is not yet linked to a person record, the page asks an administrator to link it under Manage > People.
Rows represent people and columns represent time. Project pills show scheduled allocation, leave badges show time away, holiday styling marks public holidays, travel icons show planned or confirmed trips, event pills show organization events, and red cells indicate over-allocation conflicts. Amber cells are conflicts that were accepted on the Conflicts page; hover one to see who accepted it and when. Hovering a project pill, leave badge, holiday badge, travel icon, or event pill shows its detail. On a touchscreen, tap a leave badge, holiday badge, travel icon, or event pill instead and the same detail stays up until you tap elsewhere. Tapping a project pill is different: if you can edit the grid it opens the cell editor, which shows the same detail and lets you change it, and if you cannot it shows the detail like the other markers.
Use the layer toggles to show or hide Projects, Leaves, Holidays, Travel, Conflicts, Events, and Notes. Group people by project, director, team manager, or location, then sort by name, location, team, or role. The Roles filter narrows the grid to people in the roles you select (tick multiple); its starting selection comes from Settings > View Defaults. You can also show inactive people and allocation percentages.
Turn on the Notes layer toggle (next to Events) to show note markers in the grid. Anyone who can view the grid can add a note: hover a person and period cell, click the note icon, and write the note. You then answer two separate questions. Who can see this note (everyone with grid access, or only the people you name) and who needs to act on it, chosen as specific people and/or whole roles. The two are independent, so you can post something the whole team can read while asking only one person to do something about it. When you choose everyone, the label tells you how many people that actually is before you commit to it. Sharing with everyone also offers Require acknowledgement: the note then stays in each person’s badge until they press Got it, rather than clearing when they simply open it, and you get a list of who has confirmed and who has not. A note shared with everyone stops counting toward people’s badges once it expires (the end of the period it is pinned to, or thirty days, whichever is later), so an old announcement cannot keep nagging someone who was away when it went out. Notes addressed to named people never expire; those stay until closed. A small chat icon appears in cells that have a note. Open the note to read it and exchange comments with anyone who has access. The note details show who wrote it and how long ago (hover the relative time for the exact timestamp), and a View in grid button that jumps back to the cell the note is anchored to. Only the note author can edit the note text or change who can see it after it is posted. Any recipient can close a note (closed notes switch to the closed color set in Settings > Color Defaults); only the note author can delete it. The Notes button in the left sidebar opens a panel listing every note available to you, and shows a badge counting only the notes that need you. The panel groups them the same way: Needs you, Other notes, and Closed. A note addressed to you (one you wrote, one that names you, or one aimed at your role) counts until it is closed. A note shared with everyone that is not addressed to you counts only until you have read it: opening it clears it from your badge, and Mark all read at the top of the Needs you section clears the rest in one go. Where a note does both (everyone can read it, and it names you or your role), being addressed wins: it stays until the note is closed, and Mark all read leaves it where it is rather than pretending you have dealt with it. Unread shared notes are shown in bold with a New marker, so a note that has already been round the team stops competing for attention with the ones still waiting on you. Editing a shared note does not put it back in anyone’s badge: people who already read it are not asked to read it again, so correcting a typo will not re-notify the whole team. If a change genuinely needs everyone to see it, post a new note. Notes live in the app. Nobody can email a note directly to somebody: what reaches people by email is their own summary, set up under My Profile > Notifications, which lists the notes addressed to them alongside their approvals and conflicts. A note shared with everyone that does not also name them never causes that email, and appears in it only if they have switched announcements on there. The open and closed marker colors are configured in Settings > Color Defaults > Notes.
It jumps the Plan Grid to a particular person and period and flashes that cell. You get the button in note details (open a note from a grid marker or the Notes panel), on each row of the Conflicts page, and on the Allocations, Leaves, and Travel tabs of the Approvals page. The grid switches to the view, year, and month the cell belongs to before flashing it. If the person is on the grid but their row is hidden by your current filters, the grid relaxes those filters rather than failing: first it shows inactive people, un-hides that person’s role, adds them to the people filter (the Filter people box on the name column), and expands the collapsed sections that person sits in, and only when every one of them is collapsed, since a single open section already shows their row, so the rest of your collapsed sections are left as they are. If that still is not enough it clears the grouping and its section filters, because a grouped section only lists people allocated to that section’s project and so has no row for an empty cell. It stops as soon as the cell is visible, so the second step only happens if the first was not enough, and a message tells you what moved. A filter that was relaxed stays relaxed once the jump succeeds, because putting it back would hide the cell you just jumped to. If the jump still fails nothing is kept: every filter is put back exactly as it was. When the cell simply is not in the current grid (a period outside the loaded range, or a weekend hidden by work-week-only display), your filters are left alone and you are told the cell is not shown in this view instead.
Month view gives the annual plan, week view gives near-term scheduling detail, and day view gives the most granular availability picture. On the current year, month view opens scrolled to the current month and week view to the current week, so you start at today rather than January; scroll left for earlier periods. Other years open at the start. If work-week filtering is enabled in Settings, day view can hide non-working days across allocations, leave, holidays, and travel. To see another year, use the arrows either side of the year, or type a year from 2020 to 2040 into the year field: the grid loads it once all four digits are in, and an unfinished entry goes back to the year on screen when you leave the field or press Escape.
Allocations can have phases such as Planning, Fieldwork, and Reporting. When an allocation created at one granularity appears in another view, it is shown with the configured inherited-allocation style so planners can tell it came from a coarser or different time level. In the cell editor, an inherited row is marked with an inherited badge; hover it to see where the value comes from. Where the cell averages finer records, such as a month cell fed by week allocations, changing the phase or team applies to those records and leaves the weeks as they are, while changing the percentage replaces them with one value for the whole cell. Where the value comes from a coarser record that also covers other periods, any edit creates an override for this cell alone and leaves the coarser record untouched.
Yes, and you can change them from there. When you click a cell that has allocations, the cell editor shows that person’s leave, public holidays, and travel for the period in a Time away this period section at the foot of the editor, below the allocation rows and the project search box. Each kind gets its own labelled group: the Leave group lists each booking as one row with its type, number of days, dates, and status, the Public holidays group lists each holiday with its date, and the Travel group lists each trip with its status, destination, length, and dates. Anything awaiting approval carries an Awaiting approval badge on its row. Public holidays are matched on the person’s country, so when no country is set the section says so rather than showing none. A cell with no allocations opens the project picker rather than the cell editor, and the picker carries the same Time away this period section under its project list, above its Add Leave and Add Travel buttons, with the same groups, badges, and edit and delete buttons, so leave and travel can be corrected from a cell that has no projects on it. Deleting from the picker closes it, unlike deleting from the cell editor, because the picker is pinned to the cell you opened it from and the grid reloads underneath it. Leave and travel rows have edit and delete buttons when you have modify access to that area for that person and the period is open. Editing opens the same compact form as Add Leave or Add Travel, pre-filled with the record, and replaces the cell editor, so if you have unsaved allocation changes you are asked first. Because travel is stored as one record per traveller, editing a trip opens the whole trip rather than one person’s share of it: the Travelling box lists everyone booked on it that you have access to change, so a change to the destination, dates, or any other detail moves them all together instead of splitting the trip in two. Remove a name there to delete that person’s record, or search someone in to add theirs, exactly as on the Travel page. If someone on the trip is outside your access, the form says how many rather than naming them, and warns that their records stay as they are, so use the Travel page or ask an administrator when the whole trip has to move. Deleting is the opposite and stays with the one person: it takes them off the trip and leaves the other travellers’ records untouched, which is what its confirmation names. Deleting asks to confirm and then reloads the grid with the editor still open. Two limits, both about leave being stored one day at a time and grouped into runs for display. A run that reaches the edge of the period you opened may continue into the next one, so its dates are locked in the form and a link points you to the Leave page to move them; its type, status, and notes can still be changed there, and deleting removes exactly the days the row listed. And when a plan lock window starts or ends part-way through the period you opened, the buttons are withheld altogether, because the editor may be holding only the part of a booking that window leaves visible or writable. A trip is judged on its own dates as well, so one that runs out of the period you opened and into a locked window loses its buttons even when the period you clicked is open. Use the Leave page or the Travel page in that case, where each day is handled on its own.
It is a plain 0 to 100 percent scale of that person for that period, so a bar filling the whole track means fully booked. Past 100 percent the bar stays full and turns red, and the exact figure is beside it; the Conflicts page carries the detail of what overlaps. When the person has time off in the period, a hatched band marks that share at the right of the track and a line beneath reads, for example, Away 6 of 22 working days, with a note of how many of those days are still awaiting approval. Working days come from the work week configured in Settings, and leave awaiting approval counts as time away, the same as it does on the grid and the dashboard. That line counts days and stops there: it gives no share of remaining capacity, and it never restates the allocation against the days left. An allocation percentage is a share of that person rather than a draw against a budget, so time off lowers what a booking delivers instead of capping it. That is why the Dashboard scales its person-weeks down by the same days off, and why the Conflicts page ignores leave entirely and flags a week only when the percentages across projects add up to more than 100. The one exception is a period the person is away for entirely, where the line also names what is booked, for example Away 22 of 22 working days, allocated 100% while away. Note that the analysis export takes the other view on purpose: its Capacity & Utilization sheet divides allocated man-weeks by available ones, so it reports a booking that outruns someone’s remaining days as over-allocated. That is a reporting measure for planning capacity, not the same judgement the grid makes.
Users with Grid modify permission can edit cells directly. Multi-select mode lets editors add allocations, apply a phase, or remove allocations across multiple cells. The percentage field controls the amount of capacity assigned to the selected project and period. A percentage must be above 0 and no more than 100, and decimals are allowed. You can clear a percentage field and type a new value; while a field is empty or out of range it is outlined in red, and Save changes in the cell editor, Add in the cell editor, and Allocate in multi-select mode wait until it is fixed.
Yes, from any cell. You need modify access to Leave or to Travel; modify access to the Plan Grid itself is not required, and each button appears only for the one you have. If you can also edit the plan, clicking a cell that already has allocations opens the cell editor, which carries Add Leave and Add Travel in its footer beside Add Note, and clicking an empty cell opens the project picker, which carries the same two buttons under its project list, with anything already booked in that cell listed above them. If you cannot edit the plan, clicking any cell opens that picker with no project list, just the buttons you have access to. A period the plan lock has closed for leave or for travel drops that button on its own, so a window that freezes the plan can still leave both open. Each opens a compact form pre-filled with the cell period, in a single date field you can type over or re-pick from its calendar, so you can log a trip or leave without leaving the grid. Opening one from the cell editor closes it, so if you have unsaved allocation changes you are asked first, the same as when you edit a leave or trip from the Time away section. Leave is for the cell person only. Travel starts with the cell person in a Travelling box, and you can search there for anyone else on the same trip and add them, or remove the cell person, exactly as on the Travel page; each traveller gets their own travel record with the same destination, dates, and details. The optional Project field is a search box as well: type part of a project code or name to narrow the list instead of scrolling it, and use its clear button to record the trip against no project. The record is created the same way as on the Leave and Travel pages, so if your workspace requires approval it waits for sign off before it is confirmed, and if one traveller cannot be saved (for example someone outside your scope) the form says who was saved and who was not.
When your workspace requires approval for a Plan Grid change, that change shows as a dashed, greyed "ghost" pill that does not count toward capacity or conflicts, sitting next to the live allocation it affects (which stays on the grid and keeps counting). An hourglass marks a change awaiting approval; a crossed circle marks a rejected one, with its label struck through; and a pending removal is struck through with a trash icon. Hovering shows the status and what the change proposes, for example New allocation 50%, Capacity to 80%, or Removal requested. Editors can click the cell to open its editor, where live allocations are editable at the top and requested changes are listed below showing current to proposed; from there an editor can edit the live allocation to revise a proposal, or use Cancel to withdraw one. Approving or rejecting a change happens on the Approvals > Allocations tab. See "How do allocation approvals work?" for the full process.
The Legend is dynamic. It explains project colors, allocation phase styling, conflict styling, event styles, travel icons, holiday styling, leave styling, the shared awaiting-approval marker, and the dashed ghost pills for Plan Grid changes awaiting approval or rejected, using the organization color defaults configured in Settings.
Overview is the high-level timeline view for projects and events. It offers a Gantt-style view for schedule shape and an Outlook-style calendar view for calendar inspection.
Own-scoped Overview shows the linked user only when that person record is a Director. If the linked person is not a Director, the page explains that the overview is not available for that account.
Toggle Projects and Events, filter by project type when available, filter by director, and navigate by year. The arrows step a year at a time in the Gantt view and a month at a time in the Outlook view; in the Gantt view you can also type a year from 2020 to 2040 into the year field, and it loads once all four digits are in. Default hidden project categories come from Settings, but users can change visibility during a session. A project without both a start and an end date has no place on the timeline, so it is left out of both views, and so is an event with no dates at all. An event with only one of its dates is shown as a one-day event on that date, as on the Events page. A note above the timeline says how many of the projects and events your filters include are missing a date, and hovering it lists them with the date each one lacks (press Escape to close the list). Set the missing date in Manage to bring one back. With Overview access scoped to Own or Team, a project only reaches the Overview when someone in scope directs or manages it, or is staffed on it in the year you are viewing, so an undated project can be listed in the note for one year and not another.
Use Overview to understand project and event timing at a glance, then use Grid to inspect who is assigned, how much capacity is allocated, and whether leave, holidays, travel, or events create availability pressure.
Events shows organization-level activities in month, week, day, and Outlook-style calendar views. It is useful for leadership meetings, training windows, audit committee dates, reporting milestones, or other context that should sit beside the project plan.
Use the month, week, and day buttons at the top, or drill in by clicking a period header: in month view click a month header to open the full year of weeks scrolled so that month sits at the left edge, and in week view click a week header to zoom into that weeks days. The arrows step through years. Clicking an event name or colored bar opens the event details instead of drilling.
Yes. Use the Group control to organize the calendar rows into collapsible sections by Category (the default), Director, or Attendees, and click a section header to collapse or expand it. The Sort control orders the events by Date, Category, Director, or Attendees, both within each section and overall. Grouping and sorting apply to the month, week, and day views; the Outlook view is unaffected.
Events can target attendee groups such as Everyone, VP, Director, Team Manager, Manager, and Assistant. The Events page and Grid event layer can filter by those groups so each audience sees the relevant planning context.
Yes. In any calendar view, click an event name or its colored bar to open its details. If your organization role has the events modify permission, the panel opens as an editable form for name, code, category, dates, color, pattern, director, contributors, visibility, and active status, and you can also delete the event; view-only users see the same details as read-only. Saves and deletions apply immediately and are recorded in Manage > Change Log.
Events are managed from Manage under the Events tab, and existing events can also be edited directly from the Events calendar by clicking an event. Event records can include name, code, category, dates, color, director, contributors, visibility, pattern, and active status.
Dashboard summarizes total man weeks, projects with allocation, allocated people, average allocation per project, monthly allocation trends, project totals, person totals, planning stats, total travel per person, and travel locations.
Filter by year, project categories, project types, directors, people roles, teams, allocation phases, and whether leaves or public holidays should be excluded from capacity. The Include inactive people and projects toggle covers both at once: leave it off and allocations and travel belonging to a person or a project marked inactive are left out of every chart, table, and headline figure on the page; turn it on to count them for historical review. Charts and tables update from the same filtered dataset.
Exclude leaves or holidays when you want project workload converted to available working capacity. Include them when you want raw allocation weeks without absence or public holiday adjustments. When leaves are excluded, an Include pending leave toggle (on by default) controls whether leave still awaiting approval reduces capacity; leave that has been rejected is never counted. On the allocation side, only approved allocations count toward allocated capacity here and on the grid and Conflicts page; a pending or rejected allocation change is never counted until it is approved.
Yes. Settings > View Defaults includes Dashboard defaults for excluding leaves, excluding holidays, including inactive people and projects, and hiding selected project categories or project types by default. Users can still change filters during a session.
Approvals has five tabs: Allocations, Leaves, Travel, Skills, and Certifications, each with its own pending count. The Allocations tab lists Plan Grid changes that an editor made directly and that are awaiting approval, one row per record showing person, project, period, percentage, phase, and a Change or Remove label that says whether the pending item is an edit or a requested removal. Its policy is configured under Settings > Approvals > Plan Grid. The Leaves tab lists leave awaiting approval. The Travel tab lists travel awaiting approval, one row per trip. The Skills tab lists skills awaiting approval and the Certifications tab lists certifications awaiting approval, each one row per record. Every queue starts with the most recently requested item at the top, and every column header sorts: click one to sort by it, click it again to reverse the direction. On the Leaves tab, Dates sorts by the first day off and Days by how long the request is.
Plan Grid approvals, shown on the Allocations tab, follow the same prepare and approver process as leave and travel, but you choose which kinds of change need approval. Under Settings > Approvals > Plan Grid you turn approval on and tick which change types are gated: new or removed allocations (this also covers a percentage change), phase changes, and team changes. A change whose type is not ticked is applied immediately without approval, so phase or team edits can be left ungated while capacity changes still need sign off. Editing an already approved allocation never changes it straight away: the current allocation stays live and keeps counting, and your change is held as a proposal for an approver. The proposal appears on the Allocations tab with the person, project, period, percentage, phase, and a Change or Remove label, plus a View in grid button that jumps to that person and period on the Plan Grid. Approve to apply it to the allocation, or reject to decline it and leave the current allocation as it was; when rejecting you can add a note explaining why. A gated removal works the same way: the allocation keeps counting until the removal is approved (which deletes it) or rejected (which keeps it). A brand-new allocation that needs approval waits as pending and does not count until confirmed; removing an allocation that is still pending or was rejected happens immediately. An allocation added or changed by an exempt person, or for an exempt person, is approved automatically, and the auto-allocate wizard bypasses the gate. A pending or rejected proposal does not count toward a person's capacity or raise a conflict, but it still shows on the plan grid as a dashed, greyed ghost pill next to the live allocation so you can see and resubmit it: an hourglass marks one awaiting approval, a crossed circle marks a rejected one (whose label is struck through), and hovering shows both the status and what the change proposes (for example New allocation 50%, Capacity to 80%, or Removal requested). A pending removal is shown struck through with a trash icon. Clicking a cell opens its editor: the live allocations stay editable at the top, and any requested changes for that cell are listed below under a Requested changes heading showing current to proposed, so you can compare. If you are an approver for a pending item in that list, it also carries approve and reject buttons so you can decide it there without leaving the grid, with an optional note when you reject. To change a proposal, edit the live allocation and save; to call it off, use its Cancel button, which withdraws the requested change and leaves the allocation as it is (you do not need an approver to cancel your own request). Once approved, the proposal is applied and counts as usual. You only see the requests you are an approver for, while administrators see all.
Yes. Settings > Approvals > Plan Grid has separate toggles for new or removed allocations, phase changes, and team changes. Tick only the change types that should need approval; unticked types are applied immediately without approval. A percentage change follows the new or removed allocations toggle. This lets you, for example, require approval when capacity is added, changed, or removed while letting planners adjust phase and team freely. The approvers and exemptions set on the same page apply to whichever change types are gated.
When a workspace requires approval for leave, newly added leave waits for an approver before it is confirmed. Anything waiting on you also shows as a count on the Approvals item in the sidebar. The Leaves tab groups pending leave back into the range it was submitted as and shows the person, dates, number of days, leave type, leave status (Planned or Confirmed, or whatever statuses your workspace configured, shown as Mixed if the days of one request no longer agree), who requested it, and when, with a View in grid button that jumps to that person on the Plan Grid. Approve to confirm the leave or reject to decline it; when rejecting you can add a note explaining why, which the submitter sees under the Rejected badge on the Leave page. A rejected leave is removed from the plan grid but stays on the Leave page, tinted red with a Rejected badge. Rejected leave is hidden on that page by default: when a year has any, a Rejected button above the list says how many and shows them, and an editor can clear them out from the same place. There are two ways to send it back for approval: edit it, or simply add leave for the same dates again. Either way the approver policy is re-run and the days return to pending (or are approved if approval is no longer required). Adding the same dates again also confirms how many rejected days went back for approval. If you are an approver, you can also decide leave straight from the Plan Grid: a leave cell awaiting your approval shows an hourglass marker you can click to open an approve or reject dialog, with an optional note on reject, and approving a day approves the whole range it was submitted as. You only see the leave requests you are an approver for, while administrators see all. Who approves is configured under Settings > Approvals.
Travel approvals mirror leave approvals. When a workspace requires approval for travel, newly added travel waits for an approver before it is confirmed. The Travel tab shows one row per trip with the person, location, dates, travel status, who requested it, and when, with a View in grid button that jumps to that person on the Plan Grid. Approve to confirm the trip or reject to decline it; when rejecting you can add a note explaining why, which the submitter sees under the Rejected badge on the Travel page. A rejected trip is removed from the plan grid but stays on the Travel page, tinted red with a Rejected badge. Rejected trips are hidden on that page by default: when a year has any, a Rejected button above the table says how many and shows them, and an editor can clear them out from the same place. To send a rejected trip back for approval, edit it: saving the change re-runs the approver policy and returns the trip to pending (or approves it if approval is no longer required). Pending trips still appear on the grid with the plane icon and a small hourglass awaiting-approval marker; if you are an approver for that trip you can click the hourglass to approve or reject it without leaving the grid, with an optional note on reject. You only see the travel requests you are an approver for, while administrators see all. Approvers, exempt roles, and exempt people are configured per area under Settings > Approvals.
Skills and certifications follow the same prepare/approver process as leave and travel. When a workspace requires approval for skills or certifications, a newly added record waits for an approver before it is confirmed. The Skills tab shows one row per skill with the person, topic, level, and interest; the Certifications tab shows one row per certification with the person, issuer, certification, and dates. Approve to confirm the record or reject to decline it; when rejecting you can add a note explaining why, which the submitter sees under the Rejected badge on the Capabilities page. A rejected record is left out of profiles and analytics but stays on the Capabilities page with a Rejected badge, and a pending record is tagged there with a Pending badge. Rejected records are hidden on that page by default: when there are any, a Rejected button beside the filters says how many and shows them. There is no bulk clear here; delete the individual row if you want it gone. To send a rejected skill or certification back for approval, edit it: saving the change re-runs the approver policy and returns the record to pending (or approves it if approval is no longer required). A record added by an exempt person, or for an exempt person, is approved automatically. You only see the requests you are an approver for, while administrators see all. Approvers are configured per area under Settings > Approvals.
It is still there, hidden by default. A rejected record is kept rather than deleted, so you can read the reason and send it back for approval, but it is not a booking anybody is acting on: the plan grid, the dashboard and the exports all leave it out, and so does the list it lives on until you ask for it. On the Leave and Travel pages, when the year you are looking at has any, a Rejected button appears above the list with the number in it, for example Rejected (3); switch it on and the rows appear, tinted red with their Rejected badge and the approver note. The Capabilities page works the same way on both its tabs. If a period has nothing but hidden rejections the list says so rather than claiming there is nothing there, so a refused booking is never silently missing. Editors get a Clear rejected button next to the toggle on Leave and Travel, which deletes the rejected rows currently listed, keeps any that fall inside a locked planning period, and leaves the decision itself in the change log. There is deliberately no bulk clear on Capabilities, because that list has no year to scope it to; delete the individual row instead. You are also told about a refusal without going looking for it: your summary email reports anything of yours turned down since the last one, with the reason and a link back to the record. That link opens the page with the rejected rows already shown, and on the year the record is in, so you land on it rather than on an apparently empty list. A refusal that spans several days is reported once, as the booking you submitted, not once per day. Nothing badges you about a refusal in the sidebar, because a refusal has no end state of its own and a badge for it could never be cleared.
Yes, by editing it. A rejected record keeps its normal Edit button; read the rejection note, correct the record, and save. Saving rechecks the current approver policy: if approval is still required the record returns to pending and reappears in the approver queue with a fresh request, and if approval is no longer required, because the policy is off or the person is now exempt, it is approved right away. For leave, editing a rejected range re-runs the check for every day in it at once. If nothing needs changing, opening Edit and saving as-is still resends it. Leave has a second route, because a rejected day stays booked in the calendar: adding leave for a date that was rejected, from the Leave page or the Plan Grid, resubmits that day rather than creating a duplicate, applies whatever type, status and notes you just entered, and tells you afterwards how many rejected days went back for approval. Editing a rejected range resubmits it just as reliably, but says so through the badge changing to Pending rather than a message. A date that already has leave which is approved or still pending is never overwritten: it is left as it is and the confirmation says how many days were left alone, and if every day in the range is already taken that way the save is refused outright rather than appearing to work. Both modals also warn you about either case before you save.
Yes. When you reject a leave, trip, skill, or certification request, a box opens where you can add a note explaining the reason. The note is optional, so you can leave it blank. If you add one, the submitter sees it under the Rejected badge on the Leave, Travel, or Capabilities page, so they know what to fix before resubmitting. The note is cleared once the record is resubmitted.
Yes, for the requests you qualify to decide. Pending Plan Grid changes, leave, and travel each show an hourglass awaiting-approval marker on the grid. For an allocation change, click the cell to open its editor and use the approve or reject buttons beside the pending item under Requested changes. For leave or travel, click the hourglass marker on the cell to open a short approve or reject dialog. Rejecting always offers an optional note that the submitter sees, and approving a leave day approves the whole range it was submitted as. You only see these controls for requests you are an approver for; everyone else sees the marker as a plain status icon. Skills and certifications do not appear on the grid, so they are decided on the Approvals page as before.
A conflict is a person-period where total allocation exceeds available capacity. A week total averages day allocations across the five working days, exactly as the Plan Grid does, so someone booked full time on two days of a week counts as 40% of that week rather than 200%. A week is also flagged when a single day inside it is over capacity, which happens when two projects book the same day; the row then names that day and shows what the week averages, because the grid week and month cells for that period will look within capacity. Conflicts are always measured by week, so a month row on this page reports its worst week rather than the month as a whole. Where a month has uneven weeks, its grid column averages them and can read within capacity while a week inside it is over; the row says so and names the week. The Conflicts page groups these issues so planners do not need to scan the whole grid manually.
Switch between week and month views, filter by role or person name, and use the grid shortcut to jump directly to the conflicting period. The shortcut opens whichever grid view actually shows the figure on the row, so a week the month column averages away opens in week view, and a single over-booked day opens in day view. The table shows total percent, overage, and the allocations that caused the issue. Accepted conflicts are hidden by default; turn on the Show accepted toggle to include them.
Users with conflict modify access can remove an editable allocation directly from the conflict row, split multiple editable allocations equally, or accept the conflict as intentional. Aggregated day allocations still need to be edited in the grid.
Accepting marks an over-allocation as intentional: the conflict is hidden from the default list and no longer counts in the sidebar Conflicts badge, and its grid cells turn amber instead of red. In week view Accept covers that week; in month view it covers every conflicting week of that month. You can add an optional note, and the accepted row shows who accepted it and when. Turn on Show accepted to review accepted conflicts and use Un-accept to reopen one. If the allocation total later grows beyond what was accepted, the conflict automatically reappears as active.
Travel records planned and confirmed trips by person, project, location, date range, status, purpose, and notes. The dates come first on the form and are one field holding the whole range: type it, or open its calendar and click the first and last day of the trip. Travel appears in the grid and dashboard so planners can understand travel load and availability. If your workspace locks a planning period and that lock covers travel, trips running through it are frozen or hidden; a trip that crosses the edge of the period is treated as inside it.
Yes. Editors can add or edit travel with person search and selected tags, which allows one travel workflow to create or maintain records for multiple people. The same person search is in the Add Travel form opened from a Plan Grid cell, which starts with that cell person and lets you add the rest of the party. Project is optional on a trip and is chosen the same way on both forms: type part of a project code or name to narrow the list rather than scrolling it, pick the match, or clear the box to leave the trip with no project. Only active projects are offered, except the one already recorded on a trip you are editing, which stays selectable. The Travel page can also filter by year, status, and one or more selected people.
Planned travel is tentative and useful for forecasting. Confirmed travel is committed and should be treated as stronger scheduling context. The app uses distinct status badges and grid icon colors for each.
The Region list on Add Travel comes from Settings > Dropdown Options > Travel. It starts with seven built-in regions (North America, South America, Europe, Africa, Middle East, Asia, and Oceania) and an admin can add, remove, reorder, or rename them there. Renaming a region also relabels the trips already recorded under the old name. Region is optional on a trip, and each region can be given a color under Settings > Color Defaults > Travel.
If your workspace requires approval for travel, newly added travel is held as pending until an approver confirms it. This is separate from the Planned/Confirmed status. Pending travel still appears on the plan grid with the plane icon plus a small hourglass "awaiting approval" marker and is flagged in the cell hover tooltip; the Travel page tags it with a Pending badge; and it shows in Approvals > Travel for the line manager or approving roles to approve or reject. A rejected trip is hidden from the plan grid (and left out of travel figures) but remains on the Travel page, tinted red with a Rejected badge. Rejected trips are hidden on that page by default: when a year has any, a Rejected button above the table says how many and shows them, and an editor can clear them out from the same place. Travel added by an exempt person, or for an exempt person, is approved automatically. Approvers are configured under Settings > Approvals.
Leave tracks absences by person, date range, leave type, status, source, and notes. Records are grouped into readable ranges in the Leave page and appear as leave badges in the grid.
Leave and travel dates are one field holding the whole range, not separate start and end boxes. You can type it: 1/12/2026 - 31/12/2026, or a single date for one day. Days can be written day-first (1/12/2026) or as 2026-12-01, with . / or - between the parts, and the two ends split by a dash or the word to; if you type them the wrong way round they are swapped for you. Text the field cannot read is outlined in red and put back to the saved range when you leave the box. Or click in the field, or the calendar button beside it, to open the calendar (Down arrow does the same from the keyboard): two months open below the field, you click the first day of the range and then the last, and the days between are highlighted as you move the pointer. The calendar closes itself on the click that completes the range. For a single day, click that day and press Apply. Cancel puts back the dates the calendar was opened on, and Escape does the same. Single arrows move a month, double arrows move a year, and Today comes back to this month; the arrow keys move a day at a time, Page Up and Page Down move a month, and Enter picks the focused day. Under the calendar it states the range and how long it is, and on leave forms how many working days that is, because leave is only recorded on those: a Friday-to-Monday range is four days but two days of leave. Days outside your organization's working days are dimmed, and a public holiday for that person carries a dot. Only holidays that fall on a working day are dotted, which is exactly the set the 'Skip public holidays' tick box acts on: a holiday on a weekend or other non-working day is already left out of the leave, so nothing is skipped for it. On the Leave and Travel pages the calendar opens on the year the page is filtered to, so planning a later year does not start you at today. The field is the same on the Leave page, the Travel page and the grid quick-add forms.
Days that are already a public holiday are left out of the leave you add. When the range you pick covers one, the Add Leave form names the days and offers a "Skip public holidays" tick box, which is on by default, so the leave is recorded on the remaining working days only. Untick it to record leave on the holidays as well. The same tick box appears when you change the dates of an existing leave range, on the Leave page and in the grid cell editor's quick add, because moving a range re-expands it. Public holidays are matched on the person's country, set under Manage > People, so when no country is set nothing can be matched and the form says so instead of showing a tick box. A workspace with no holidays on record sees neither the tick box nor that message, since there is nothing to skip. Only holidays ticked as non-working under Manage > Holidays count, so a holiday your organization works through never blocks leave. A public holiday that falls outside your working days is not counted either, because leave was never going to be recorded on that day: over a Christmas that runs Friday and Saturday on a Monday-to-Friday work week, the form names the Friday only. If every working day in the range is a public holiday, the save is refused and you are asked to untick the box if you meant it. Skipping is about counting: leave on a public holiday never made the person any less available, since they were already away, but it did add to their leave days. Bulk import is not affected and still records those days, because it mirrors your leave system; the validation step reports how many days in the file fall on a public holiday so you can check them.
If your workspace requires approval for leave, newly added leave is held as pending until an approver confirms it. Pending leave still appears on the plan grid like normal leave, marked with a small hourglass "awaiting approval" icon and split out in the cell hover tooltip; the Leave page tags it with a Pending badge; and it shows in Approvals > Leaves for the line manager or approving roles to approve or reject. A rejected leave is hidden from the plan grid (and left out of capacity figures) but remains on the Leave page, tinted red with a Rejected badge. Rejected leave is hidden on that page by default: when a year has any, a Rejected button above the list says how many and shows them, and an editor can clear them out from the same place. Because the day is still booked there, adding leave for that date again resubmits it for approval instead of creating a second record. Leave added by an exempt person, or for an exempt person, is approved automatically. Approvers are configured under Settings > Approvals.
Yes. Leave statuses come from Settings > Dropdown Options > Leaves and start as Planned and Confirmed. Add, remove, reorder, or rename them there and the Leave page, the grid quick-add, and the leave import template all follow, with the first status in the list used as the default. Leave saved with a status you later removed keeps it until you edit that record. Each status can be given its own color, fill, and pattern under Settings > Color Defaults > Leaves.
Import and Manual are leave sources. Import covers leave added via file upload or the API. Manual covers leave entered directly through the Leave page. Use the source toggles to show or hide each type.
Manage includes a leave import wizard for .xlsx and .csv files. Download the template, upload the completed file, validate rows, preview errors, and import valid rows. Date ranges are expanded to individual days and non-working days are skipped unless configured otherwise. Public holidays are not skipped on import, unlike leave added by hand, because an import mirrors your leave system; the validation step reports how many days in the file fall on a public holiday for the person concerned so you can check them before importing. Rows dated inside a planning period whose lock covers leave are reported as failed rows with a reason, and the rest of the file still imports.
Yes. Manage > Leaves includes an error report email and an API key panel. Editors can generate or revoke a leave API key, copy it once, download a Windows upload script with the leave template, or use the documented curl pattern to validate or import files programmatically. Three endpoints accept the key as a Bearer token: GET /api/[org]/leaves/people returns active people with their emails (used to build the file), GET /api/[org]/leaves/leave-types returns configured leave types, and POST /api/[org]/leaves/upload?import=true imports a completed file. API imports are logged as API import and set the leave source to Import. Keep the key private because it can import leave without a user login.
Yes. The Leave table can be sorted by date, person, type, status, source, or notes. Imported leave is read-only in the Leave page, while manually entered leave can be edited or deleted by users with modify access. If your workspace locks a planning period and that lock covers leave, days inside it show a padlock instead of the edit and delete buttons, or do not appear at all; ask an administrator what is locked.
Capabilities has Skills and Certifications tabs. Skills track person, topic or area, experience level, and interest. Certifications track person, issuer, certification, issue date, and expiry date.
Search by person, topic, or certification and filter by topic, level, interest, or issuer. Users with modify permission can add, edit, and delete skills or certifications; view-only users can use it as a staffing reference. Own-scoped Capabilities limits both the Skills and Certifications tabs to the linked person record.
If your workspace requires approval for skills or certifications, a newly added record is held as pending until an approver confirms it. The Capabilities page tags a pending record with a Pending badge and a rejected one with a Rejected badge. It shows in Approvals > Skills or Approvals > Certifications for the line manager or approving roles to approve or reject. A rejected record is left out of person profiles and analytics but remains on the Capabilities page. Rejected records are hidden on that page by default: when there are any, a Rejected button beside the filters says how many and shows them. There is no bulk clear here; delete the individual row if you want it gone. A record added by an exempt person, or for an exempt person, is approved automatically. Approvers are configured under Settings > Approvals.
Manage is the operational data workspace. It contains People, Projects, Access, Events, Holidays, Leaves, and Change Log tabs. It powers the planning views, filters, permissions, and audit trail.
People records include name, email, team, person role, line manager, city, country, color, and active status. The line manager can be used as an approver for that person under Settings > Approvals. Active people appear in planning by default, while inactive people can be included with filters for historical or future review. A person record can also be linked to a user account so Own-scoped permissions know which records belong to that user.
Projects include name, code, category, type, color, start and end dates, director, team manager, and active status. These fields drive grid display, Overview timing, grouping, filtering, dashboard analytics, and default color rules. The project table has its own From and To date filter, which starts on the current year, plus a search box, so a project planned for a later year is not listed until you widen the range. Saving still works either way: when you add or edit a project that falls outside the current filter, the range stretches to include it and a search term it does not match is cleared, so the row you just saved stays on screen.
Bulk Allocate is a five-step wizard: select projects and a date range, split each project into phase date windows (a default percentage split with per-project overrides), pick people per project and choose each person's role, set an allocation percentage per role and phase, then review before creating allocation records. Alongside the built-in director, team manager, and contributor roles you can define your own roles (e.g. Backup Team Manager) in Settings → Bulk Allocate, where you also set the default phase split and the percentage matrix. Allocations are tagged with the matching phase, existing allocations can be skipped or overwritten, and phase windows plus people-and-role picks are saved for the next run. Review the result because generated allocations still need planning judgment.
Each upload wizard provides a template, accepts completed Excel files, validates rows, previews valid and invalid rows, and imports only valid rows. People upload supports teams, roles, city, country code, colors, and active status. Project upload supports categories, types, dates, director, and team manager.
The Holidays tab groups public holidays by country, supports country search, date filtering, manual add/edit/delete, collapsible country groups, and a sync flow that can include extra countries. Every column sorts: click Date, Name, Type or Non-working to order the rows inside each country group, and click Country to flip the order of the groups themselves. Sorting by Non-working is the quick way to bring the days still waiting on a decision to the top, and ticking a box does not move its row out from under you: rows hold their place until you sort again or reload. Sync pulls from a public holiday calendar for every country your people are in, for this year and next, and covers three kinds of day: public holidays, bank holidays, and optional holidays. School holidays and observances such as Valentine's Day or Mother's Day are never included, because they are not days off work. Each row shows which kind it is, next to a Non-working tick box. That tick box is the one that matters: it says whether your offices are actually closed that day, and it is what the rest of the app reads. Public holidays arrive ticked. Bank and optional holidays arrive unticked, because only you can say whether your organization closes for them: a bank holiday is often an eve such as Christmas Eve or New Year's Eve, which some offices close for and others work, and an optional holiday is a day most people take off without it being a general public holiday. After a sync, the tab tells you how many newly added days are waiting for an answer, then filters the list to every day currently marked as worked and opens the country groups holding them, so you can settle them together. Untick anything your organization works through, such as a public holiday that is official but not generally taken off. A holiday that is not ticked is an ordinary working day everywhere else: it shows no marker on the plan grid, does not count as time away, does not reduce capacity on the Dashboard or in the analysis export, and does not stop leave being booked on it. It stays listed here so you can change your mind. Your answers survive future syncs, so a day you unticked is not re-ticked the next time you press Sync, and a holiday with no classification recorded shows as Unclassified: either you added it by hand, or it was synced before this tab started storing them.
Open Manage > Projects and use the Plan lock card above the project table. Turn the plan lock on, then add a locked period: give it a name, a start month, and optionally an end month (leave the end month empty to lock everything from the start month onward). Periods are set by month because allocations are locked by the period they start in. Press Save to apply, including the on/off switch. Under "This locks", tick what the period closes: Projects, Grid notes, Leave, Travel, Events. Anything left unticked is untouched and stays visible and editable inside the period as usual. For each thing you tick, choose what the lock means: "Hidden" removes it for everyone else, and "View only" leaves it visible but unchangeable. The two choices are independent, so you can hide the projects while making the leave view only, or lock the leave and nothing else. New locked periods start with Projects hidden and nothing else ticked, because the usual reason to lock a period is keeping an upcoming engagement confidential rather than closing the period for work. A period must lock at least one thing; if you untick everything, remove the period instead. Ticking Projects covers every project that starts inside the period (a project with no start date counts from its earliest allocation), together with every allocation made in the period. A hidden project does not exist for everyone else: it is gone from Manage, the Overview, the Plan Grid, Bulk Allocate, the Dashboard, Conflicts, Approvals, profiles and the change log, along with all of its allocations and any trips linked to it. Everyone else also cannot create a project that starts in a locked period, or move a project into one. While the plan lock is on and any locked period that has not ended ticks Projects, every project needs a start date, for everyone including administrators: a new project cannot be saved without one, an existing one cannot have its date cleared, and a project upload rejects rows without one. Events work the same way while any period ticks Events. Projects created before that with no start date are placed by their earliest allocation, so adding an allocation before a locked period makes such a project visible to everyone; Manage marks them "No start date" so you can set one. A project that started before the period and runs on into it stays visible, although its allocations inside the period are still locked. A view only project stays visible but cannot be edited or deleted, and takes no new allocations. Ticking Events does the same for events, by the date each one starts, on the Events page, Manage > Events and the Overview. In Manage, projects and events covered by a lock carry a Hidden or View only badge, so the people who keep access can see which ones everyone else is missing. Deleting a person or a project also removes or changes the records that hang off it, so everyone else cannot delete one while that would reach anything the lock covers: the allocations, leave, trips or grid notes of that person inside a locked period, a locked project or event the person is director or team manager of, contributes to or attends, a locked note the person receives, or the allocations and linked trips of that project inside a locked period. The delete is refused with a message that the planning period is locked, and nothing is removed. Hiding something removes it from the Plan Grid, Overview, Dashboard, Conflicts, Approvals, the change log and profile pages, and view only leaves it there but refuses every change, including approving a request against it. Ticking Leave or Travel applies everywhere those records appear, including the Leave and Travel pages, so days a person has already booked inside the period are hidden or frozen for them too, and an imported leave row dated inside the period is reported as a failed row rather than imported. Travel is judged on its whole date range, so a trip that runs across the boundary is treated as inside the locked period. A locked period still appears on the Plan Grid as a normal column, emptied of whatever is hidden, so people can carry on using it for everything that is not locked; the column disappears altogether only when Projects, Grid notes, Leave and Travel are all set to hidden (events are not on the grid, so Events makes no difference to that). Then tick the roles that keep access. A role you tick works in the locked period exactly as it does elsewhere, so a role with view-only access to the grid still cannot edit it. Access is granted by role rather than to named individuals, so to give one person access, put them on a role that has it. Administrators always keep full access, so a workspace cannot lock itself out. An API key has no role, so an integration is treated like anyone else and cannot write into a locked period. On the Plan Grid, a Locked marker appears beside the year picker whenever the year you are viewing has locked or hidden periods; for administrators it is a button that opens this setting. Excel exports are administrator-only and are not filtered, so an export run by an administrator still contains the locked period.
The Change Log records key create, update, delete, approve, and reject actions, including role changes, role definitions, API key events, imports, and allocation, leave, travel, skill, and certification approval decisions. Where available, it stores old and new values so reviewers can see what changed. A bulk action, such as deleting a leave range, changing a phase across the grid, or a leave import, is written as one entry that names the people and projects it touched and the date span it covered, alongside the count, so you can tell what the batch actually did without opening the records. Long lists are shortened to the first few names followed by a count of the rest. Entries about a locked planning period are withheld from anyone the plan lock hides that period from, so two people with Manage access can see different entries. Entries are kept for up to two years from the day they were written, then removed automatically.
Open Settings > Approvals and select the area (Leaves or Travel). Turn on Require approval, which selects Line Manager by default, then choose the approvers: the person's line manager (set per person under Manage > People), anyone holding one or more selected roles, and/or specific named people. At least one approver is required while approval is on. You can also list roles or specific people who are exempt: their own records, and any they add for other people, are approved automatically. While the switch is off, everything in that area is approved automatically. If a particular person has no line manager or matching approver, administrators can approve. Leaves and Travel are configured independently. The remaining areas (Allocations, Skills, Certifications) are shown for a future release.
Settings > Notifications sets the workspace default for the summary email: how often it goes out, on which day, at which hour, and, most importantly, in which timezone. The built-in fallback is every Monday at 08:00 Amsterdam time, which is the middle of the evening in Sydney and the small hours in California, so setting this once is worth doing. It applies to everyone who has not chosen their own schedule, including people who join later. It is a default and never a rule: it cannot override an individual’s own setting, and changing it does not move anybody who has already chosen. There is deliberately no control here for deciding who receives the summary or forcing it on somebody. Nobody can send this email to anyone; each person subscribes to their own, so the only thing an administrator sets is where everybody starts. Setting the workspace to Never means nobody is emailed unless they switch it on for themselves. Each person changes their own under My Profile > Notifications.
Settings > Notifications has a Delivery problems panel below the schedule. It lists anybody in this workspace whose address the app has stopped sending to, and it covers every message the product sends, not only the summary email: set-password links and import reports stop arriving too. An address lands there for one of three reasons. It bounced, which usually means a typo or a mailbox that no longer exists. The person marked one of our emails as spam, in which case we stop sending to them and the right fix is to ask them, not to force it. Or our email provider is refusing the address outright after earlier failures. When the panel is empty it says so, which is the answer to whether email is working at all. Correcting the address under Manage > Access is the usual fix, and it works straight away because the corrected address was never blocked. Try again tells the app the address is worth another attempt: it does not repair anything at the email provider, so if the address is genuinely dead the next failure puts it straight back on the list. Allow a minute for a Try again to take effect. The list itself updates within seconds of a failure, because our email provider tells us as it happens rather than us checking periodically. This panel is the only place this information is shown, so an administrator who can reach Manage but not Settings will not see it.
General settings control the organization name, workspace URL slug, working days, and whether day view hides non-working days. Changing the workspace URL changes the /org/... address, so old bookmarks and shared links stop working, and other signed-in users may need to sign out and back in.
Dropdown Options define selectable values used across the app: teams, people roles, project categories, project types, project phases, event categories, travel regions, leave types, leave statuses, capability topics, capability levels, interest levels, certification issuers, and certification names. Admins can add, remove, reorder, save groups, or rename values. Renaming a value updates every existing record that used the old name, and every setting that referred to it: its color, the view defaults that hide it, and any approval policy that names it all follow the rename instead of being left behind under a value the dropdown no longer offers. Because a rename rewrites records in every period, a plan lock limits it: while a locked period ticks Projects, a team or phase can only be renamed by people who keep access to that period, and the same goes for leave types and statuses under a leave lock, travel regions under a travel lock, and people roles under a grid notes lock. Project categories, project types and event categories can always be renamed, since renaming a label changes no plan.
Color Defaults control project color rules, event color rules, event and phase fills or patterns, holiday styling, leave status styling, and inherited allocation styling. Defaults can also be applied to existing projects or events where supported.
Terminology lets authorized users rename key labels such as Director and Team Manager. These terms appear in project forms, event ownership, grouping controls, filters, dashboards, grid labels, and upload templates.
View Defaults set the starting state for grid, timeline, and dashboard views. Grid defaults include visible project categories, visible people roles, default grid view, grouping, sorting, holiday display, inactive people, percentage display, and layer visibility for projects, leaves, travel, conflicts, events, and notes. Dashboard defaults include leave and holiday exclusion, inclusion of inactive people and projects, and default visible categories and types.
Manage > Access has Users and Roles sub-tabs. Users assigns email addresses to named roles, links users to person records, removes access, and can set a password directly or email a set-password link to an existing workspace user. Setting a password directly takes effect at once, and because somebody other than the account holder chose it, that person is required to replace it with one of their own the next time they sign in. The link is the alternative that avoids a shared password altogether: it lets that person choose their own straight away and stays valid for an hour. A password they already have keeps working until they use it, though any earlier reset link they were sent stops working as soon as a new one is issued. If the email cannot be delivered an error is shown and their password is left unchanged, so the action can simply be retried. Roles defines named permission sets with module-level view and modify rights. System roles cannot be modified, while custom roles can be created for your organization.
Base access is the broad role level, admin or member. Module permissions decide whether a role can view or modify each product area. Scoped modules can be set to All, Team, or Own. The left navigation and API access both use these resolved permissions.
Own and Team scope are available for Grid, Overview, Conflicts, Travel, Leave, and the Skills side of Capabilities. On the Overview, scope shows the projects the people in scope direct, manage or are staffed on that year and the events they direct, contribute to or attend, and team member counts include only people in scope. Both use the user account linked in Manage > Access to a person record: Own limits access to that person only, while Team limits it to everyone sharing that person's Team (set in Manage > People). If no person is linked, scoped pages may show no records or block writes until the link is fixed; if the linked person has no Team, Team scope behaves like Own.
Sync People creates or updates user access rows from people records that have an email address, links each user to the matching person record, and assigns the default member role where needed. It reports synced, linked, already complete, and skipped-no-email counts. It is useful after bulk people uploads or email cleanup.
Your signed-in name and resolved organization role appear at the bottom of the sidebar. Your name links to My Profile, and Sign out ends the current session. The sidebar footer also holds the Feedback button, the Manual FAQ, the Guided Tour link (for users who can view Manage), and, when permitted, the billing status. A separate help assistant button sits in the bottom-right corner of the page.
My Profile > Notifications has a Summary email schedule. Choose every day, every week or every month, pick the day and the hour, and pick the timezone the hour is measured in. The timezone list starts on your own computer’s zone if it is not already one of the common ones. The summary lists what is currently waiting for you: approvals you can decide, over-allocations in your scope, and notes that need you. It also tells you when a request of yours was turned down, with the reason the approver gave and a link to the record so you can change it and resubmit it or remove it; the link shows the rejected rows and opens on the right year, since they are hidden by default. That part covers what was decided since your last summary rather than everything ever refused, so you are told once. It is the one thing in here that nothing else chases you about: a refused booking simply sits on its page, hidden by default, and the app will not badge you about it. It is only ever sent when there is something in it. A summary that arrives to say nothing needs you is one you stop opening. The same panel tells you when one was last actually sent to you, so a stretch with no email is visibly a quiet stretch rather than something broken. Notes shared with everyone are the one thing it treats differently, and only when they are not addressed to you as well: a note that names you counts as yours however widely it was shared. An announcement asks nothing of you, so it never causes a summary on its own, and it is left out of one entirely unless you switch on Include notes shared with everyone. Even then it only rides along in a summary that an approval, an over-allocation or a note addressed to you had already earned, or that a request of yours being turned down had earned. That is the one place the summary and the sidebar badges differ on purpose: the badge counts an announcement you have not read yet, the email does not chase you about it, and a refusal works the other way round because only the email reports it. Everything in it links straight to the page or the note it came from. Until you choose, you follow your workspace default, which an administrator sets under Settings > Notifications, so a workspace in Sydney is not left on a UTC morning that lands at six in the evening. If nobody has set one, that default is every Monday at 08:00 Amsterdam time, so the app can tell you something before you have discovered any settings screen at all. Choosing your own schedule stops you following the workspace: change it there later and yours stays put. There is a link to go back to following it. Setting yours to Never means never, whatever the workspace says. No administrator can override an individual choice in either direction. Turning it off means this app will not email you at all about work in progress; the badges still show everything when you are in it. You do not have to come here to stop it: every summary email carries its own link to turn itself off, and mail programs that show an Unsubscribe control next to the sender name can use it too. Following the link in the email turns off the summary for the workspace that email came from, and leaves any other workspace you belong to alone. Using your mail program's own Unsubscribe control is broader, because it is a message to the sender rather than to one workspace: it turns the summary off everywhere. Either way the choice lands in this panel, so you can turn it back on here whenever you want. If you set a schedule for a time that has already passed today, the first summary arrives on the next one, not within the hour. Monthly schedules stop at the 28th so that February never skips a month.
The lower-left status shows the current subscription state: trial days left, active billing, scheduled cancellation, overdue payment, canceled billing, or not started. It links to Settings > Billing when your role can view billing.
Billing shows seat count, estimated monthly or annual total, subscription status, trial end, renewal or access end date, invoice history, and payment method. It can start card checkout, start invoice billing, open the Stripe portal, and show checkout success or cancellation messages.
A new workspace gets a 90-day free trial. Workspace admins receive an email about 14 days and about 3 days before it ends, and another within a day after it has ended (the reminders go out once a day, in the morning UTC). When the trial ends without a subscription, the workspace is paused and shows a "Your free trial has ended" page until an admin adds a subscription in Settings > Billing. While a workspace is paused after its trial, Settings stays open to everyone and Manage stays open to workspace admins, so they can add their team first: billing counts active people as seats and needs at least one. Workspaces that have a subscription (including a canceled one) or a billing override get no trial emails.
Invoice subscriptions use the configured net payment period. If an invoice remains overdue after the grace period, the workspace can be blocked until billing is resolved. Billing-blocked users are routed to Settings so payment can be fixed.
Once a subscription is fully canceled, Settings > Billing shows the start options again (card checkout or invoice billing). Starting one creates a new subscription and lifts the billing block. The free trial only applies to first-time signups, so a workspace that already had a subscription starts billing immediately on resubscribe rather than getting another trial. A subscription that is only scheduled to cancel at period end is not canceled yet: use Resume subscription instead while it is still active.
Yes, at two levels. The database itself is on a hosting plan with automated daily backups kept for 7 days, which covers the whole platform and is only used for disaster recovery. Separately, your workspace gets its own restore points: a copy of your planning data is saved every night, immediately before every bulk change such as an import, a bulk edit or an auto-allocate run, immediately before any restore, and whenever a full admin asks for one. Those restore points are listed in Settings > Backups, where a full admin can download one or roll the workspace back to it. We keep the last 7 nightly restore points (up to 8 days), the last 10 you create by hand (up to 30 days), and ones taken before a bulk change or a restore for 7 days. A restore point has to be inside both limits to survive, so a nightly copy goes once seven newer ones exist even if it is not yet 8 days old. The Backups tab shows when each one will be removed.
Go to Settings > Backups, which is visible to full admins only. Pick a restore point and press Restore. You then choose whether to restore everything or only certain areas such as Leave, Allocations, Travel, Events, Public holidays, Skills and certifications, Grid notes or Settings. Press "Check what this will change" to see exactly how many rows would be removed and restored before anything happens, then type the workspace name to confirm. People and projects can only be restored as part of a full restore, because allocations, leave, travel and everything else are attached to them. A restore point is saved automatically just before the restore runs, so a restore you did not mean to do can itself be undone.
Only a full admin, meaning someone whose role grants view and modify on every module. Holding the Settings page alone is not enough. Every restore is written to the change log with who ran it, which restore point was used and how many rows moved, and every other full admin is emailed afterwards. The notification is sent after the restore rather than before, because the restore is already reversible by then.
Yes. A restore point is taken automatically immediately before every Excel import of leave, people or projects, every bulk edit of allocations or leave, and every Bulk Allocate run. Go to Settings > Backups and look for the entry marked "Before a bulk change" with a time just before you ran it, then restore it. One caution: these are taken at most once every ten minutes, so if you ran several in quick succession the restore point may predate the first of them, and restoring will undo all of them together. If the change could not be backed up for some reason it still runs. An Excel import or a Bulk Allocate run then says so on its result screen; a bulk edit made on the grid or the Leave page runs without that warning.
The app includes an organization-scoped export route for major planning data, including people, projects, allocations, leaves, travel, events, holidays, changelog, and settings. It is intended for audit review, backup, analysis, and migration support.
From Manage, admins see an "Export for analysis" button in the top-right corner. It opens a small dialog where you pick a date range, then downloads a multi-sheet Excel (.xlsx) workbook for that range. Unlike the raw data export, this is a denormalized, analysis-ready workbook: foreign keys are resolved to names and it opens with About and Data Dictionary sheets that explain the domain and every column. It includes People, Projects, Project Phases, a denormalized Allocations fact table (with man-weeks), a computed Capacity & Utilization sheet (working days, public holidays, leave, available vs allocated man-weeks, utilization percentage, and over-allocation), an Allocation Heatmap shading each person by month from idle through fully booked to over-allocated, a native stacked-column Allocation Chart with its editable Chart Data sheet, a Skills Matrix, Certifications with expiry, Time Off, and Travel. It is built to drop straight into a pivot table or be handed to an AI assistant to answer questions such as who is over-allocated and when, which projects consume the most man-weeks, or where skill gaps exist. Admin-only.
No. The in-app help assistant only receives the message you type into it, together with the product manual it answers from. It never sends your organization's workspace data (people, projects, allocations, leave, travel, capabilities, or any records) to the AI provider, and it is read-only, so it cannot see or change your data. Messages are processed by our AI sub-processor (Anthropic) purely to generate a reply. Under Anthropic's commercial terms, inputs and outputs sent through the API are not used to train their models, and they are deleted within 30 days by default. Anthropic is listed as a sub-processor in our Privacy Policy.
The public site links to Privacy Policy, Terms of Service, Cookie Policy and Sub-processors pages, and a Security page covering how to report a security problem. The app uses strictly necessary authentication/session cookies and shows a first-visit cookie notice with Accept analytics / Decline options. Accepting sets one optional first-party analytics cookie so visitor counts are more accurate; declining keeps measurement fully cookieless. Either choice is remembered and can be changed by clearing cookies.
Email security@auditschedule.com. The public Security page at /security is the full policy: what is in scope, what we ask of you while you are testing, how quickly we reply, and the safe harbour that applies to good-faith research. We acknowledge a report within 5 working days and reply substantively within 10. We do not run a bug bounty. The same contact details are published in machine-readable form at /.well-known/security.txt. Test only in a workspace you created: every other workspace holds another company's data.
The public site has a What's New changelog page listing product releases with their dates and a summary of new features, improvements, and fixes. This is the product-wide release history; for changes made inside your own workspace, use Manage > Change Log instead.
Check project date ranges, active people, linked user/person records, role permissions and scopes, default filters, leave and travel records, event visibility, and color defaults. After bulk uploads, auto-allocation, approvals, API-key imports, or syncs, use validation results and the Change Log to confirm what changed.
This feature is for platform superadmins, not workspace admins. At /superadmin/marketing, open Choose a template next to New campaign and select Spreadsheet planning. It fills a new draft with a campaign name, a personalized subject and a plain-text-style message with one Explore AuditSchedule link to the homepage. Review the copy and save the draft before selecting recipients. Choosing a template does not send email. The unsubscribe footer is added automatically when sending.
This feature is for platform superadmins, not workspace admins. At /superadmin/marketing, save the campaign as a draft, tick the prospects you want in Send to prospects, set a date and time in Send at, then choose Schedule send. Times are read in your own timezone, and the campaign starts going out within five minutes of the time you pick. You can close the page once it is scheduled. Use Send now instead if you want it to go out immediately.
This feature is for platform superadmins, not workspace admins. A scheduled campaign stays editable until its send time arrives: open it from the campaign list to change the name, subject, body or recipients, then choose Reschedule to set a new time. Cancel returns it to draft and discards the queued recipients without sending anything. Once the send time passes the campaign is marked Sending and can no longer be edited, rescheduled, cancelled or deleted, because part of the mail may already have gone out. A campaign that is sending still shows Stats, where each recipient reads as Queued, Sent, Failed or Skipped, so you can watch it land.