Advanced Settings

Open Settings > Organisation Settings to manage organisation-wide defaults. The page has searchable navigation grouped into Organisation, Workflows, Finance, and Security, so profile, schedule, project-planning, billing, rate-card, sign-in, and web access controls are separated into focused sections. What you can change depends on your role and permissions.

On a phone or tablet, use the searchable section picker above the current settings. It offers the sections your permissions allow. On desktop, use the navigation beside them. Selecting a section brings its heading and controls into view.

Open Clients separately to manage client organisations and shared client assets. The Finance group’s sections (Finance setup, billing entities, tax rates, numbering, activity codes, expense categories, bank accounts, custom fields, budget templates and the catalogue) are covered in Finance Setup.

Choose tracking features

Open Settings > Organisation Settings > Tracking. Organisation settings permission is required to make changes.

Task tracking is always available. Time and expense tracking follow Finance by default, so a workspace without Finance starts with tasks only. Switch Time tracking or Expense tracking on or off independently. Changes save immediately. Choose Use Finance defaults to make both follow Finance again.

Switching a feature off hides its navigation and prevents new time entries or expense claims. Existing records are retained. When time tracking is off, task completion asks for notes without asking for hours. Scheduling and estimates remain available. Expense claims also need a billing entity and categories configured in Finance setup.

Organisation preferences

Organisation administrators can update profile and operating defaults, including the organisation logo and contact details, website, locale, currency, address, and timezone.

The following settings directly affect project planning:

Setting	Effect
Top-Level Project Label	Chooses whether master projects are called Campaigns, Programmes, Initiatives, Engagements, Workstreams, or Project Groups throughout the app.
Daily capacity	Sets working hours per person per day for capacity planning, overload warnings, and the initial estimate when a new task is scheduled. Name-only backlog tasks do not receive an estimate. Values are kept between 1 and 24 hours; the default is 8. This is the figure used for anyone without a working pattern; a pattern sets that person’s days individually.
Timezone	Sets the local calendar used for task dates, working days, closure dates, dependencies, capacity, and automatic planning. The default is Australia/Sydney.
Working hours and lunch break	Sets the local day boundaries used when AI planning and automatic scheduling spread task hours.
AI project planning defaults	Sets budget rules, planning objective, financial display, and rate-card confirmation for brief-driven draft projects. Client rules can override these defaults.
Allow direct project creation	Lets users with project-create access create a draft project without first generating a brief and resource plan. New organisations start with this on; administrators can turn it off.
Brief Builder AI review	Chooses whether people must wait for the current AI review to finish before sending a brief to Planning. New organisations start with Planning allowed during a review; administrators can switch it to wait.
Chat assistant step limit	Sets how many tool-use steps the Chat Assistant (Ru) can take for one message before it asks for a follow-up. Values are kept between 1 and 2000. New organisations start at 100. Existing organisations keep the value they already have, and any organisation without this setting falls back to 10 until an administrator changes it.
Project lifecycle and archiving	Controls the incomplete-task check when projects close or archive, the default handling for automations and integrations, and automatic archiving of finished projects. New organisations start with automatic archiving on; administrators can turn it off.

When direct creation is enabled, + New → New project offers Brief Builder and an empty-project path. When it is disabled, the same action opens Brief Builder directly. See Creating Projects.

Settings also contains the organisation’s base rate-card roles, user cost/rate assignments, and client-specific rate cards. See Rate Cards for the planning model.

Choose the timezone where the organisation plans its working day. The selector shows the current local time so you can confirm the choice before saving. Runnit keeps date-only values on the selected calendar date and keeps local working-hour times stable through daylight-saving changes. Existing task timestamps remain the same moments in time, but their displayed local date or time can change when an administrator changes the organisation timezone. The task editor’s calculated finish and automatic daily plan follow the new timezone. Milestone target dates stay on their saved calendar date, and new milestones default to today in the organisation. Custom daily allocations keep the dates entered until you deliberately edit them. See task scheduling.

Choose the first day of the week

Admins and owners can set one choice for everyone in the organisation:

Open Settings > Organisation Settings.
Select Work schedule and capacity.
Set First day of the week to Monday or Sunday.
Choose Save changes. Choose Reset to discard an unsaved change.

Sunday is the default until you change it. The choice applies to Schedule’s month, week and list views, capacity grids, resource planning and weekly Gantt groupings. Date navigation follows the selected week start. Existing task dates and working-day capacity stay the same. There is no individual override.

If saving fails, the error appears and your selection stays available to retry. Continue to Resource Planning.

AI project planning defaults

Organisation administrators can choose:

Budget constraint: required, optional, or disabled for non-commercial work;
Planning objective: commercial efficiency, balanced, or timing and capacity;
Financial mode: billable, internal cost, chargeback, or hidden; and
Rate-card selection: use the default automatically, confirm when several cards exist, or always confirm.

They can also choose whether Proceed to Planning waits for the current Brief Builder AI review. The default prevents handoff while evaluation or refinement is running. An administrator can allow handoff during evaluation when the organisation deliberately prefers speed over waiting for the latest review.

These rules are stored with generated draft projects so activation can enforce a required budget or rate-card review. Edit a client to apply different rules for that relationship.

Project lifecycle and archiving

The Project lifecycle and archiving section in the Workflows group controls what happens when projects finish:

Incomplete tasks on completion or archive: when a project moves to done, completed, cancelled, or archived while it still has incomplete tasks, Runnit can do nothing (Off), ask the person to confirm and choose what happens to the tasks (Warn, the default), or refuse until the tasks are completed or cancelled (Block).
Default handling for automations and integrations: what non-interactive writers (automations, API integrations, auto-archive) do with incomplete tasks: leave them, complete them, or cancel them. Under the Block policy, leaving tasks unresolved fails the operation and the failure appears in the automation run trace.
Auto-archive finished projects: when enabled, projects that stay in the selected statuses (done, completed, or cancelled) longer than the chosen number of days (1 to 3650, default 30) are archived automatically. New organisations start with this on, archiving all three statuses after 30 days; organisations created before this default keep it off until an administrator turns it on. Projects already past the threshold are archived on the next run after you enable it. Automatic archives appear in the project history attributed to auto-archive, and org administrators are notified when the incomplete-task policy blocks one.

Archived projects are hidden from lists and boards and are read only until someone with the archive permission unarchives them. See Project Management.

Task table default columns

The Task table section under Workflows sets which columns the project task table opens with across the organisation. Use standard columns keeps Runnit’s built-in layout. Customise columns lets you tick standard, financial, and shared custom columns on or off and reorder them, with a live preview of the resulting header row. Financial columns only ever appear for people with financial access.

These are defaults only. Each person’s own column changes and saved views take precedence, and Reset to default columns in the table’s Columns menu returns to this layout. A kanban board can override the organisation default for its own projects from the board editor’s Table tab; see Kanban boards.

Chat assistant step limit

The Chat Assistant works through a request in steps: each step lets it read or change workspace data with its tools. When a single message needs more steps than the limit allows, the assistant stops and asks you to send a follow-up so it can continue. Raise the limit in Projects and AI planning if multi-step requests (for example, planning a full task list with research and concept images) regularly stop early. Higher limits can use more AI credits for a single message. The limit accepts 1 to 2000 steps. New organisations start at 100; organisations without a stored value fall back to 10.

Web access

The Web access section in the Security group controls which websites the Chat Assistant (Ru) can fetch when it researches for you: client sites, competitors, news, reference pages, and product documentation. Only owners and admins can change it.

Ru never asks before fetching a site. Every site is either fetched or refused:

Blocked domains are refused. When someone asks Ru to read a blocked site, Ru says that an admin has blocked it and carries on without it.
Trusted domains are the platform trusted list plus any domains you add under Additional trusted domains. Trusted sites are fetched exactly like any other public site. The label only marks them as routine sources in the organisation’s fetch record.
Every other public site is fetched as normal and recorded as unlisted.

The Platform trusted list is seeded by Runnit, is the same for every organisation, and is read-only. It covers major news publishers, Wikipedia, community sites, government and regulators, standards bodies, advertising and marketing trade media, and the help centres of common business tools. Use the search box to check whether a site is on it. To stop Ru fetching one of these sites, add it to your blocked domains: blocked always wins.

To add an entry, type a domain such as example.com and press Enter or Add. A domain covers all of its subdomains, so reddit.com also covers old.reddit.com. Start an entry with *. to cover subdomains only. You can paste several domains separated by commas or spaces, and a full web address is reduced to its domain. Entries that are not domain names (an IP address, a single word, or text with spaces) are refused with a message that names the entry. Each list holds up to 500 entries.

Changes are not applied until you choose Save web access. Discard changes returns both lists to what is saved.

Two-factor policy

The Two-factor policy section in the Security group lets the organisation owner require two-factor authentication for chosen roles. Admins can see the policy but not change it.

Tick the roles that must have it (for example Owner and Admin) and select Save policy. From then on, anyone in a ticked role who signs in with a password is taken to the two-factor setup steps straight after signing in and cannot use anything else until it is on. Nobody is locked out: the setup is always available, and people already enrolled notice nothing. People who sign in through a provider such as Google or Microsoft are not affected, because the provider manages their second factor.

Everyone can turn two-factor on for themselves whatever the policy says. See Two-factor authentication for the steps and for recovery codes.

Administrators can also review the organisation’s mode-aware AI usage. If the organisation uses platform credits, they can check its balance and top-up options. If it uses its own provider accounts, they can manage those encrypted keys. See AI Usage & Model Settings and AI Credits.

To add trusted external tools to Ru, open Settings > Agent Integrations. See Agent Integrations for remote MCP discovery, fixed HTTP operations, credentials, testing, and availability.

The organisation’s own files live in Settings > Organisation Library: the AI Library collections the assistant reads while it works, and the organisation’s own brand collections used for internal projects. Client organisations have their own Clients page; old Settings links redirect to the right place. See Assets and AI Directives.

To create isolated demo, sandbox, or training data, open Settings > Datasets. See Datasets for creation, switching, seeding, and Production safeguards.

Client organisations

The client list shows every client organisation along with key details and how many users it has.

Viewing your clients

Each client in the list shows its name, status, contact details (email, phone, and address), and a count of registered users. Status badges make it easy to see which clients are active, inactive, or pending at a glance.

Editing a client organisation

You can edit a client organisation’s details, but only when it’s a client you set up and that nobody from the client side has joined yet. The page shows a clear indicator and an Edit button for clients that qualify.

A client is editable when both of these are true:

It has no registered users.
It was created by someone from your organisation, not by a member of the client organisation.

When you edit, a form opens pre-filled with the current values. You can update the organisation name (required), email, phone, address, city, and country, then Save or Cancel.

Why some clients can’t be edited

Situation	Editable?
You created the client and no one from it has joined.	Yes: you set it up on their behalf.
Someone from the client organisation has signed up.	No: they now manage their own profile.
The client relationship was created by a member of the client.	No: it’s self-managed from the start.

This protects a client’s profile once they start managing it themselves.

Managing a client staffing list

Open the client’s Team tab to see whether initial planning uses every active staff member or a selected staffing list. Choose Set Staffing List to select staff by name or email. Once set, use Add to List or Remove to maintain the default pool. Removing the final member restores the all-staff default. Project owners can still add another active staff member to one project without changing the client list.

If the staff list fails to load, use Try again in the dialog. The save action stays unavailable until the list has loaded and at least one person is selected. For the full workflow and its effect on project visibility, see Client Organisations.

Deleting client data

When an engagement ends, you can clean up a client’s data from the danger zone on the edit client page. Two options are available:

Option	What it removes
Projects, jobs, and assets only	Clears engagement data but keeps the client organisation and its files.
Delete everything	Removes the client organisation, the relationship, and organisation-level assets in addition to the engagement data.

Once the purge runs, a summary shows what was removed and whether the client organisation itself was kept. You’ll only be returned to the Clients page if the client relationship was removed; otherwise the page stays open and refreshes the list.

Workspace maintenance

A move to a new dedicated environment creates its destination automatically. You do not need to create a workspace there first.

Your workspace stays available while the destination is prepared. If preparation fails before maintenance starts, the workspace stays where it is and your current sign-in, API keys and MCP connections continue to work.

Published project forms, their attached records and saved values move with the workspace. You do not need to detach records or delete forms before a move. See project record forms.

During a workspace move, you may see This site is under maintenance. Wait and select Try again. Your workspace address stays the same. Other workspaces sharing the affected service may also be temporarily unavailable. Your existing address continues to work while network caches update. You do not need to clear your DNS cache or use a different address after the move.

If a move needs recovery, maintenance can continue while the service is restored. Wait for the workspace to reopen. Once it accepts changes again, retrying the move’s recovery does not replace those changes with the earlier backup.

When the workspace reopens, sign in again with your existing sign-in method. Google or Microsoft sign-in continues to work; you do not need to create a password for the move. If a sign-in attempt fails, start again from the workspace’s login page. See signing in after a move. If you use an API key or a connected AI client, create a new key or reconnect the client. See API keys and authentication and MCP connections.

App activity

Owners and admins can open Organisation > App activity to inspect active members, app areas, business events and API response codes when collection is enabled. Filters and permissions are explained in App activity.