A specification here has three layers. Each stores only what differs from the one beneath it, so a correction made upstream reaches you unless you have changed that note yourself.
The three layers
- The platform library. A shared set of notes, placed into a tree for each type of project. A note is shown to practices only once it has been issued, and you see it as issued.
- Your practice's specification. Your own version of that tree. You edit a library note for your practice, write notes of your own, and hide or move others.
- A project's specification. Built from one of your trees for a particular job. You leave out the notes that do not apply and reword others for the job.
Before you start
Specification must be switched on in Settings → Modules: see Turning modules on and off. Owners, admins and anyone given the Specifier role can edit your practice's specification. Other members can read it.
Your practice's specification
Open Specification in the rail and choose a project type.
- Editing a library note makes your own copy. It applies to your practice only, in every project type where the note appears, and records which revision of the note it was taken from. Saving a note unchanged makes no copy, so opening one never stops it receiving corrections.
- Your own notes and categories can be added, and archived but not deleted.
- Hiding a library note removes it and everything beneath it from that tree. Moving a note changes where it sits in yours.
- A newly issued library note appears where the library places it.
When the library moves on
If the library has updated a note you copied, a badge appears on Specification in the rail, and the page flags the note. Open it to see three versions side by side: the one you started from, yours, and the library's now. Choose use the platform's, which keeps your wording in the history, or keep mine, which is recorded and flagged again only if the library moves on once more. To combine them, edit your copy and keep it.
If the library withdraws something you copied, your copy stays, listed apart, and can be put back into a tree as your own.
Notes are not offered back to the library from here. To suggest one, email [email protected].
A project's specification
On a project, open its Specifications page. A project can hold several, such as a tender specification and a construction specification. Each starts from one of your trees.
Until you first issue it, a project specification follows your tree. Issuing pins it: from then on, changes to your tree do not move it. The project's page shows when your tree has changed, with a list of what was added, removed, renamed, reworded or moved. Bring up to date takes the tree as it is now. It keeps the notes you left out for the job and the wording you changed.
A specification can be read on screen and downloaded as a PDF. A working copy is marked DRAFT.
Issuing revisions
Each issue is a record: Rev A, then Rev B and so on. Its content is stored in full and never changes, so Rev A reads the same for as long as it exists. An issue is refused if nothing has changed since the last one, or if the specification has no notes in it.
Sending a revision to a client
Send a revision through the same links and codes as a drawing: see Sending a drawing. Sending Rev B to someone who has Rev A gives them a new link to Rev B. Their Rev A link does not change, but it tells them a newer revision was sent. Each person's activity records exactly which revision they were given.
Sharing between your own practices
If you run more than one practice, one can lend its specification to another, read-only, from Settings → Modules → Specification. The practice receiving it can then start a project's specification from the lender's tree, but cannot change it. An owner or admin of both practices must agree to the arrangement, and either side can end it. Specifications already issued from it stay as they were.