ModulesClients

Clients

A client is the organisation you are building for. Lacroo models a client the same way it models a supplier: as its own organisation, sitting on the far side of the tenancy boundary from yours — never as a contact row inside your org.

Everything a client can eventually see is an explicit grant. There is no inherited access and no org-wide visibility: one row per project, per client.

Registering a client

Clients in the org console lists every client organisation linked to yours.

New client asks for three things, plus the projects the client should have access to:

FieldWhat it is
Organisation nameThe client company’s name.
Contact nameThe person you are inviting — not the company.
Contact emailWhere their invite is sent.

The organisation and the contact are two different names and are asked for separately. The contact is a person who will sign in; the organisation is who they work for.

The projects are bound as part of the same request — if any project does not belong to your organisation the whole registration is refused and names the offending project, so a client is never left half-linked to something you did not choose.

Registering a client invites its first contact. The organisation, the contact and the contact’s invite are all created together, and the setup email goes out immediately — the same email Resend sends. You do not have to go to Contacts afterwards to invite the person you just named. Adding further people later is what Invite contact is for.

If the email cannot be sent — the mail system being unavailable, for example — the client is still registered and the invite is still valid. You are told the email did not go out, the contact shows as Not sent under Contacts, and Resend sends it. What never happens is a contact created with no way to ever sign in.

If the email already belongs to a client organisation someone else registered, that organisation is reused rather than duplicated: one contact, one client org, however many head contractors work with them. No new invite is sent in that case — the contact already exists, so use Invite contact if they still need one.

If the email already has a login anywhere in Lacroo, the registration is refused and nothing is created. A malformed email address is refused the same way.

If the email already belongs to a pending supplier organisation, the registration is refused with a message saying so. The same person can be both, but the two organisations have to be reconciled deliberately rather than by Lacroo silently creating a second record.

Status

A client link has three states.

StatusMeaning
PendingRegistered, not yet accepted. Its project grants are held as invited.
ActiveThe relationship is live and its project grants are active.
SuspendedAccess withdrawn. The client and its project grants are kept intact.

Suspending is reversible and destroys nothing. The date a client first became active is recorded once and never rewritten by a later suspend or re-activate.

Projects

Manage projects on a row adds and removes the client’s project access.

Removing a project is a soft removal: the record of the grant is kept, it simply stops counting as access. Re-adding the same project later is allowed and starts a fresh grant, so a temporary removal is not a permanent decision.

A project grant follows its client link — bind a project to a pending client and the grant waits as invited until the link goes active.

Who can manage clients

Registering clients, changing their status, binding or unbinding their projects, and editing or deactivating a contact require the Clients: manage permission, held by Master Admin, Organisational Manager, Project Admin and Engineer. Binding or unbinding a project is decided on that project, so a role held there counts.

Deleting a contact requires Clients: power, held by Master Admin and Organisational Manager only. It is the one irreversible action on this page — it permanently removes a person’s account and their details — so it sits with the same two roles that hold the equivalent power over field users.

Viewing the clients list is an ordinary read available to anyone with access to the org console. Client data is never visible to another organisation — a request naming an organisation other than your own is refused outright.

Inviting a contact

Registering a client already invites its first contact. Contacts on the client’s row is where you invite anyone after that — a second person at the same client, or a replacement for someone who has left.

Enter their email and, if you like, their name — Lacroo works a name out from the email if you leave it blank. Everything else is derived: the organisation they join, the projects they can see, and the access they get all come from the link you are inviting them on. There is nothing else to choose, and no way to widen what they see from this screen.

They receive an email with a button that takes them to a setup page, where they choose their own password and arrive signed in to their portal. You never see or set their password.

The invite code

The confirmation shows an invite code and a setup link, once. They are the manual fallback for when email does not arrive — read the code down the phone and they can enter it on the setup page instead of using the link.

That confirmation is the only place either one is ever shown. They are not on the contacts list and cannot be recovered from it. If they are lost, use Resend, which issues a new pair.

Pending, Last sent and Expires

A contact who has not set a password yet shows as Pending.

Last sent is the truth about the email, not a record of your click. If it reads Not sent, the email did not go out — usually a background-services problem worth reporting rather than something to wait on. Resending will try again.

Expires is fourteen days from when the invite was last sent. After that the link and code stop working and you send a new one. Nothing is lost; the contact simply has to be re-invited.

Resending

Resend issues a fresh code and link and emails them again.

The previously sent link stops working the moment you resend. If someone was midway through setting up with the old link, they need the new one — so resend because the first never arrived, not to chase someone who already has it.

You can resend once a minute. Clicking sooner is refused and changes nothing: the link already in their inbox keeps working.

Revoking

Revoke withdraws an outstanding invite. The link and code stop working immediately.

Revoking is not deletion — the record stays, and you can invite the same person again afterwards. If Revoke reports that the invite was not found, it had already been claimed or revoked; nothing was withdrawn just now.

To someone holding a dead link, every case looks the same: revoked, expired, already used, or never real all show one message asking them to request a new invitation. That is deliberate. It means the setup page cannot be used by an outsider to work out which invites exist.

When the email already has a Lacroo account

If the address already has a login anywhere in Lacroo, the invite is refused with an explanation rather than creating a second account for the same person.

One email is one login, across the whole product. If they already work with you through another organisation, link that existing client organisation on the Clients page instead of registering a new one.

Managing a contact who has already signed up

Once a contact has set up their account, their row offers three actions: Edit, Deactivate and Delete. A contact who has not accepted yet still offers Resend and Revoke instead — there is no account to manage until they have one.

Editing a name or an email

Editing is immediate. Changing the email signs the contact out everywhere and the old address stops working straight away — they sign in with the new address using their existing password, and any password-reset link sent to the old address stops working too. Changing only the name does not sign them out.

If the new address already has a Lacroo login, the change is refused and says so. One email is one login, across the whole product.

Deactivating

Deactivating signs the contact out immediately, on their very next action — not at some later point when a session happens to expire. While deactivated they cannot sign in and a password reset does nothing. Activating them again lets them sign in with their existing password; they start from a fresh sign-in either way.

Deactivating one contact does not affect the client organisation or anyone else at it.

Deleting

Deleting removes the contact’s account, their sign-in, their notification subscriptions and any invites they hold, and signs them out immediately. They stop receiving diary notifications from that moment. It cannot be undone.

Once a contact is deleted they leave the list for good: they cannot be edited and they cannot be activated again, and the system answers as though the contact never existed. Someone who can deactivate but not delete cannot bring a deleted contact back either.

The client organisation keeps its access: the link and its projects are untouched, and other contacts there are unaffected. Deleting a person is never a way to withdraw an organisation’s access — suspend the link for that.

Historical records that reference the person — diaries, dockets, audit entries — stay intact and readable; their identifying details are scrubbed from them.

Deleting requires Clients: power, held by Master Admin and Organisational Manager only. Editing and deactivating need Clients: manage. If you cannot see the Delete action, you do not hold that permission.

Not yet available

  • Restoring a deleted contact. Deletion is permanent. Invite the person again to give them a new account.

What the client sees once they are linked

A linked client signs into the Client Portal: their projects, and for each project its diaries across three status views — All, Submitted for Approval and Engineer Approved.

Two things are worth knowing from this side of the boundary:

  • Drafts never reach the client. A diary your site team is still writing is invisible to them, in every view and in every count. Sending a diary back to draft removes it from their list; submitting it again returns it.
  • No money and no audit trail leave your organisation. The client’s diary list carries no rates, costs or totals, and none of the internal record of who submitted, reviewed, confirmed or reverted a diary. Those fields are not hidden on their screen — they are never sent.

Dockets on a diary

Opening a diary shows the client its dockets, in three sections: Labour & plant, Subcontractor and Materials.

The labour and subcontractor tables lead with Day works item · Quantity · Unit · Applies to, then carry the docket’s own facts — docket number, supplier, supervisor, start, end, break, shift duration, personnel, plant and status. Day works lead because that is what a client reads a site record to find: what was done, and how much of it. Your own table leads with resourcing and ends in a total because it exists to be priced.

What that means from this side of the boundary:

  • No money leaves your organisation, at any depth. No rate, amount, total, cost or price appears on a client’s docket table, and none is in the data their browser receives. A day-works line reaching them carries a description, a unit and a quantity — never the rate it was priced at or the line total it produced. Those columns are not selected from the database at all, so there is nothing on the wire for anything downstream to reveal.
  • Only settled dockets are visible. Submitted, engineer-approved and confirmed dockets appear. A draft docket is invisible and uncounted, the same way a draft diary is. Nothing you are still writing up is exposed.
  • A quantity nobody has entered reads Pending, never 0. Day works carried onto a docket from a worker’s assignment show as pending until someone enters the quantity. A client is never shown a figure that was not claimed.
  • A docket with no day works still appears, with a dash in each of the four leading columns. A gap in the record would be the worse failure.
  • Materials lead with a lines count. Where your materials table shows a Total, theirs shows how many delivery lines the docket carries.
  • They cannot open a docket. Rows are inert: no sheet, no drawer, no navigation. There is no docket detail view for a client.

The diary list row also carries a docket count. It counts settled dockets recorded directly against that diary; a master subcontractor docket linked to several diaries at once is not counted on the row, though it does appear in the table when the diary is opened. Treat the row number as a floor, and the diary itself as the record.

Your own diary now shows a Day works column too, beside Total Amount, which is unchanged. It carries the description, quantity and unit — day-works rates stay where they already were, on the docket and on the Day Works workbench.

Not yet available

  • Deleting a client link. Suspend withdraws access; removing a client link entirely is not built yet.

Client notifications

Client contacts are told about diary events through Notifications; see the Notifications page for the whole screen. The three diary events a client can be told about are diary submitted, diary approved and diary confirmed.

Inherited and Overridden

Each event row on the project screen carries one of two labels:

  • Inherited — this project follows the organisation default. Change the recipients here and it becomes an override.
  • Overridden — this project owns the list for this event.

Use organisation default clears the override and returns the row to Inherited. It affects only that project and that event; the organisation default is never destroyed by a project action.

An empty list means nobody

Clearing every recipient on a project row is a real setting, not an absence. The row still reads Overridden and the event notifies nobody for that project. That is how you turn an event off for one project while other projects keep receiving it. It is deliberately different from Inherited, which means the project has no opinion and follows the organisation.

Who can read and write it

Both reading and writing require the Clients: manage permission — Master Admin, Organisational Manager and Project Admin. Reading is gated as well as writing because the list contains an external company’s staff names and email addresses.

Things worth knowing

  • Removing a project from a client silences that client for that project, without touching the configuration. The selection is retained and takes effect again if the project is bound back. Suspending the link has the same effect across every project.
  • A contact of a pending client can be configured. Nothing is sent until the link is active.
  • A new contact is subscribed automatically. Registering a client by email subscribes the contact it creates to the organisation default for all three events, in the same step. There is no separate subscription to remember.
  • Deleting a contact removes its subscriptions with it, everywhere.

Diary submission notifications

When a supervisor submits a site diary on a linked project, every client contact subscribed to diary submitted is emailed once.

The email names the project, the diary date, the shift and who submitted it, and carries a View Diary link that opens the diary inside the client portal. The link never opens the internal diary screen, which a client cannot reach.

Diary reviewed and diary confirmed can be configured but do not send yet.

What a notification never contains

A client is never sent money. No rate, cost or total appears in any notification — the same rule the portal itself follows.

When mail stops

  • Unlinking a project stops its emails immediately, even though the contact’s subscription is still on record. Access is the link, not the preference. Binding the project back resumes them.
  • Suspending a client relationship stops mail across every project.
  • Deactivating a contact stops their emails.
  • A project with no recipients sends nothing and records nothing.

Reverting and re-submitting

Reverting a diary and submitting it again sends a fresh email, so a client is told when a diary has been corrected and re-submitted. A submit request that is simply retried does not send a second time.

Custom fields are visible to the client

Every custom field on a diary is visible to a linked client. A custom field holding commercially sensitive content will be exposed, so configure project custom fields accordingly.

The Client field on a project

Project settings carry a free-text Client field. It is a label only — it drives no access and is not connected to the Clients page. Naming a client there grants nothing; only a link on this page does.