The tools catalogue
Tool Settings is where a tool is configured: its types, its statuses, its checklists, its templates and its approval workflows. It is the difference between an Inspections module and your Inspections module, and it is the single largest reason two Teralo accounts feel different from each other.
Open it from Tools in the sidebar. It renders as a grid of cards grouped by module, one card per tool, and each card opens that tool's own settings page.
It configures a tool, it does not switch one on
Worth clearing up first, because people look here for a switch that is not here.
There is no per-project on and off control for a tool. Whether a tool appears for a particular person on a particular project is decided by two other things:
- Their permission template. A sidebar item appears when the person holds at least one permission for that tool. Nothing in the template means nothing in the sidebar. See How permissions work.
- The organisation's plan. A tool an agreement leaves out is gone for everybody, template or no template. See Plans and entitlements.
What Tool Settings decides is what the tool contains once somebody can see it, and which of the organisation's configuration each project uses.
Two catalogues, one at each level
The grid exists at both levels and the pages inside it are nearly the same set of twenty-three.
Organisation, then Tools is where the standard is written: the types, statuses and templates the whole company shares.
Project, then Tools is where a project decides which of those it uses, and adds anything that belongs only to that job.
Two pages exist at one level and not the other. Estimating is organisation-only, because a tender pipeline is a business asset rather than a project one. Locations is project-only, because a location hierarchy is the physical shape of one building. See Organisation level and project level.
Write once, then activate what each project needs
This is the pattern behind almost every list in the catalogue, and it is worth learning once rather than per tool.
An entry written at organisation level is available to every project and active on none of them until somebody activates it. Open the same tool's settings on a project and the organisation's entries are listed at the top under a heading saying so, each with a switch, plus Activate All and Deactivate All for the whole list.
Below that sits the project's own list. An entry created there belongs to that project alone and is active immediately, because there is nothing to opt into.
The activation step is what makes a shared standard usable. A full spec section list runs to hundreds of entries and no single job uses all of them; a business with eleven slightly different hot works permits has them because nobody could activate a subset. Write them once, switch on the ones the job needs.
Start with the default configuration
When an organisation is created, the last step of the wizard offers Create with Defaults, and it is the recommended choice. It seeds a working configuration across the catalogue: mail types and statuses and standard responses, document types, statuses and disciplines, contract types and statuses, tax rates, retention defaults, procurement categories, meeting types, incident and injury classification lists, observation types, equipment categories and types, permit types with their checklists, induction content, submittal types and spec sections and review stamps, and a default approval workflow for each tool that has one.
Everything it writes is yours to edit, rename or delete afterwards. Starting blank is a real choice and occasionally the right one, but it means nobody can raise anything until somebody has written the list it would have been raised against.
What a new project inherits
A project created by your organisation starts from your organisation's configuration rather than from nothing.
Approval workflows come across as defaults, so a new job has a working approval process on day one rather than an empty one. See Templates and runs.
Permission templates are cloned from the organisation's base set, so the project has Project Admin, Project Manager, Contract Administrator and the rest to assign from immediately.
Inspection template categories are activated automatically, all of them, which is the one list where the sensible default is everything on.
Everything else follows the pattern above: available, and activated as the job needs it.
The workflow builder lives here too
Approval workflows are edited in the workflow builder, which is reached from the tool the workflow belongs to rather than from a card of its own. It has no card in the grid because it is not one tool's setting; it is one engine bound to twenty of them. See The workflow builder and Binding a workflow to a tool.
A tool your plan does not include
Where an agreement leaves a tool out, its card is simply absent from the grid, and so is its entry in the breadcrumb switcher at the top of the page.
Typing the page's address directly does not get round it. Teralo answers with Not included in your plan, naming the tool and pointing at your account contact, rather than an access-denied message that would send you to an administrator who cannot help.
A guest organisation has no Tool Settings at all
Tools is a Host-organisation page, at both levels. A guest organisation's sidebar shows Settings, Permissions, User Applications and Billing under its own name, and no Tools; opening the address by hand is refused.
That is worth knowing because a guest organisation does have organisation-level registers of its own, for equipment, permits, method statements, inductions and documents. Those run on the configuration seeded when the organisation was created, and there is no page to change it from. If you need something different in one of those lists, the practical route is to ask Teralo support. See Hosts and guests.
PermissionsHost only
Two permissions, and they behave as the pair everywhere else in Teralo does.
Viewing tools puts the Tools item in the sidebar and opens the grid and its pages read-only. Managing tools enables the editing on them. Managing implies viewing, so granting the second is enough.
Both are organisation-scoped at organisation level and project-scoped at project level, so somebody can be trusted with one project's configuration without being trusted with the company standard behind it. That is usually the right split: a project engineer adding a location to their own job, an office administrator writing the document type list everybody uses.
Neither permission is something an agreement can take away. Tool Settings is on the small floor of pages no plan may withhold, because a customer locked out of configuring their own tools cannot run their own account.