Portal Terms & Conditions

1Writing and publishing #

• Pick the document — Terms or Privacy — in the toolbar. They are versioned and published entirely separately.
• The grid lists every version, newest first, with its state, when it came into force, and how many customer logins have accepted it. Click one to open it.
• A draft is yours to change: edit the title, the preamble and the sections, add or delete sections, and use the arrows to reorder them. Save draft writes it; nothing reaches customers yet.
• Publish makes it the document customers see, and retires the version published before it.
• There can be only one unpublished draft per document at a time. Finish it or delete it before starting another.

2Step by step #

The portal's terms document, versioned, with acceptance tracked per customer.

1. Draft the terms as sections; save the version with F5 .
2. Publish it — customers are asked to accept on next sign-in, and acceptances log against this version.
3. To change published terms, issue a NEW version rather than editing the accepted one.

3Why a published version cannot be edited #

Open a published version and every field is read-only. That is deliberate. Customers accepted those exact words, and editing them would change what those people are held to without their knowing — quietly, and with nothing to show it happened.

To change published wording, press New draft from this . You get a copy at the next version number to edit and publish; the old version stays exactly as it was, as the record of what was agreed, with its acceptances still attached to it.

The API refuses the edit as well, so the rule holds whether the change comes from here, from the desktop ERP, or from anywhere else.

4Placeholders, and why publishing is blocked #

The seeded documents are templates. They carry markers in square brackets — [COMPANY NAME] , [CITY] , [SUPPORT EMAIL] , [INTEREST RATE] and others — for the things only you can fill in.

While any remain they are listed in an amber strip above the editor and Publish is refused . Shipping "[CITY], [STATE]" as your governing-law clause is worse than having no terms at all, and this is the cheapest place to stop it. The list refreshes each time you save.

The seeded text is a starting point, drafted to match what the portal actually does. It is not legal advice — have it read by your own lawyer before you publish.

5"Ask everyone to accept again" #

The publish dialog asks two questions. In force from may be left blank, which means immediately; a future date means the portal keeps showing the previous version until then.

Ask everyone to accept again is the one that matters. Turn it on for anything that changes what a customer is agreeing to: every portal user is then shown the new version on their next visit and cannot use the portal until they accept it. Leave it off only for a typo or a reworded heading, where existing acceptances should stand.

It is a judgement call about your own wording, which is why the screen asks instead of guessing.

6The terms gate; the privacy notice does not #

A published terms document blocks the portal: until a customer accepts it they see the terms instead of the portal, and cannot route around it. Acceptance is per LOGIN, not per customer firm — several people from one customer may sign in, and each agrees for themselves.

The privacy notice blocks nothing. It tells the customer what you do with their information; it does not ask them to agree. Locking somebody out of their own invoices until they tick a privacy box does not make the notice more truthful, and consent taken that way is worth less, not more. Customers can read, print and download it whenever they like, and it is linked from inside the terms gate so it can be read first.

7Who accepted what #

The lower grid lists every acceptance of the open version: when, which customer, which login, the person's name as it stood at the time, and the network address it came from.

Those rows are evidence. Nothing in the application edits or deletes them, and the login name is stored as text rather than looked up, so a login later renamed, disabled or reassigned does not rewrite the record of who agreed.

The Accepted by column in the versions grid is the count per version — worth a look before you republish, because it says how many people you are about to ask again.

8Writing the section text #

Section bodies are plain text, never HTML . Leave a blank line between paragraphs, and start a line with a hyphen and a space to make a bullet. That is the whole of the formatting.

Plain text on purpose: this content is typed by staff and rendered into a customer-facing page, and accepting markup would hand an injection vector to whoever edits the document. The portal, the customer's PDF and the desktop ERP's export all split it the same way, so all three agree.

Heading is what the customer sees. Key is a short stable name so code can find a section however the heading is later reworded — leave it alone unless you are adding a section.

9Why is the Document list not offering Privacy? #

The Document pick-list is not loaded from a master — it is the document types the schema supports. It is disabled, and the screen says so, when the database has not been prepared for a second document.

• A document with no versions: the script ran, but its seed was skipped because a document of that type already existed. Check the versions grid on the other document type.

The acceptance grid is empty until customers actually accept. A published document with no acceptances simply means nobody has signed in since you published it.

10Shortcut keys #

• F3 — reload the open document from the database.
• F5 — save the draft. Does nothing on a published version.
• Esc — close the publish dialog without publishing.

The keys are scoped to this page, so a second screen open in another tab keeps its own.

11If something does not work #