The client portal

Your clients receive their reports in a portal of their own, at your company's portal address or your own domain, with your logo and your colour, not ours. Client users are free and unlimited: they never count toward your plan. They see issued reports and what you release to them, never a draft, and they can comment, formally accept, raise requests and sign what you send them.

What the client gets

A client user signs in at your portal address (shown under Settings, Client portal) or at your own domain, with the account they were invited with, or with their own company account where single sign-on is set up. The portal carries your name, logo and accent colour; your contact details appear at the foot of every page if you switch that on under Settings, Organisation. Its menu is Projects, Requests and, with the Operations module, Timesheets and Extra scope, and Documents where you share any.

A person represents one client of your company. An end client's users see the projects done for them too. A former client user invited back keeps the same account.

What the client sees

• Projects: every project you carry out for the client, with the number of issued reports.
• Issued reports: one row per report number at its current revision, with the people who signed, the PDF editions to download, the verification page, the other revisions, and the files behind the report you shared. A withdrawn report shows as withdrawn with the date and its replacement, never the reason. Drafts, reports in review and void reports do not exist in the portal.
• Shared files: the folders and files you shared, per folder or per file, from the project's Files tab. Files linked to a report can reach the portal with the report at issue if you switch that on under Settings, Reports. See files and sharing.
• The tracker, drawings, repair rates, wall thickness and scope of work, once you release the project's tracker with Show to the client: read-only, from issued reports only, never a mark from the field. See the tracker.
• Sheets you shared, read-only.
• Documents: procedures and technique sheets you shared with the client from the document library, read in the page. See the document library.
• With the Operations module: Timesheets sent for signature and Extra scope raised for approval. See operations.

What a client user can do

• Comment on an issued report, under Activity and conversation. Comments are part of the report's record and cannot be changed or removed; your signers are told by email.
• Accept this report: a formal acceptance of the current issued revision, with an optional note, recorded with the person's name, the client's name and the time. It cannot be undone, a later revision is accepted on its own, and it shows on the report in your workspace and on the public verification page as the day of acceptance. See verification.
• Raise a request on a project: fill the form in, or upload the request as they have it (an email saved as PDF, a Word or Excel file, a photo of a letter). With AI switched on for your company, AI fills the form in and the client checks it before raising; without, the document comes with the request as it is. The client follows the request's status, sees the reports that answer it and each item's result from issued reports, and, where you allow it under Settings, Organisation, who does the job while it is in progress. See inspection requests.
• Request inspection on an outstanding line of the scope of work, which raises a request for those lines. See the scope of work.
• Enter the minimum thickness on a TML of a released tracker, with its basis. See thickness trending.
• Approve or Send comments on a shared procedure or technique sheet, on record with their name and the time.
• Sign the timesheet or Dispute it, and Approve or Reject extra scope, when you give the person that permission on the client's page.

A client user never signs a report, never enters a scope of work, never adds an asset, and never sees your drafts, your marks from the field or your rates and money.

Setting the portal up

Owners and admins set the portal up under Settings:

• Client portal: the portal Address that invitations link to; the Accent colour used for the portal's buttons and links; the Logo (PNG, JPEG or WebP, shown at most 40 pixels high), with a preview; and Requests from your website: Take requests from your website opens a request form anyone can fill in from a link or button on your own site, without an account. What is sent reaches you under Requests once the sender has confirmed their email address.
• Portal domain: the portal can answer on a domain of yours, such as portal.yourcompany.com, with the same sign-in and branding. Enter it under Use a domain of yours; the page shows a TXT record that proves the domain is yours and a CNAME record that sends visitors to the portal. The check runs every few minutes for a week, or at once with Check now; the certificate is taken care of. Once confirmed, emails and share links use the domain. A domain of your own comes with a higher plan; see billing and plans.

Giving a client's people access

On the client's page, Client portal access lists who signs in on the client's behalf:

1. Invite a client user with their email address and Send invitation. They receive a link to the portal that works for a few days; a pending invitation can be withdrawn.
2. Under In the portal, ... may, tick Sign timesheets or Approve extra scope for the people allowed to, with the Operations module.
3. Deactivate ends a person's access; their comments and acceptances stay. Reactivate brings it back.

Owners and admins invite and deactivate. While a client is archived, its users cannot sign in and nobody can be invited. Staff have no way into the portal by being staff: to see the client's view, invite yourself as a client user with another address.

Single sign-on for a client

Under Single sign-on for this client's people on the client's page, Set up lets the client's people sign in to your portal with their own company account through the client's OpenID Connect identity provider. The client's IT registers the portal at their provider with the redirect address shown, gives you the issuer, client ID and client secret, and proves each of their email domains with a DNS record. Only people you have already given portal access to can sign in this way, and you may enforce it for addresses in a proved domain. See account and security.

Emails the client receives

Client users are emailed, in their own language, when:

• a report is issued, once its PDF editions are ready;
• a report is withdrawn, with its replacement where there is one and never the reason;
• a member of your staff comments on a report;
• staff raise a request for the client, or change a request's status, with the note you add;
• a timesheet is sent for signature, or extra scope is raised, with the Operations module.

Nobody is told of their own comment. The emails link to the portal, on your domain where you have one.

What you see of the client's actions

Your signers, the examiner and the reviewer, are emailed when the client comments on or accepts a report; owners and admins are emailed when a client raises a request. On the report's page in your workspace, Activity and conversation shows the whole history, the client's comments and the acceptance with the person's name and time. Every acceptance, portal sign-in and download is in the organisation's Activity log, under Organisation in the sidebar. See team and roles.

Clients with their own systems

A client who wants your results in their own systems has three doors. The read-only API, under Settings, API and webhooks, reads your projects, issued reports and their PDF editions, the tracker and the thickness figures with a token you make and show once. Webhooks at the same page tell their systems when a report is issued, withdrawn, commented on or accepted, when a request is raised or moves on, when a timesheet is signed and when thickness readings change, each delivery signed. And a client who runs Weld Intra enters a one-time code from the client's page (Make a code) in their own app; their requests then arrive here as the client's, and each weld's result goes back once its report is issued. The API and webhooks come with the plans that include them; see billing and plans.