Law firm client intake: website, CRM and access boundaries

An assistant needs to call a prospective client back, a marketer needs to see where the enquiry came from, and a lawyer needs to assess whether the firm can take on the work. If they all open the same record with documents attached, convenience becomes excessive access. Law firm client intake should follow a separate route from the website to the CRM: minimum data first, controlled review next, and transfer of materials to a designated team only after a decision.

Here, CRM means a system for managing enquiries and clients, not automatic permission to see every matter. What follows is a technical process model and criteria for testing it, not legal advice. The firm determines conflict-check procedures, grounds for processing data and retention periods with a qualified specialist; integration alone does not guarantee legal compliance.

Separate an enquiry from the future matter file

The public form should help contact the person and route the enquiry, not collect a complete dossier. Start with a name or preferred form of address, a contact channel, the general subject and a short description without unnecessary detail. Request a list of parties for internal review only to the extent agreed by the firm and through a designated channel. Even a party's name can be sensitive information.

Explain beside the form what not to send and when to expect the next step. An acknowledgement does not mean the firm has accepted instructions or checked whether it can act. Agree response times with the team.

When an attachment field is unnecessary

If a document is not needed for initial contact, remove uploads. Following review, the responsible person can request materials through a controlled channel. Fewer copies do not replace protection at the next stage. A shared mailbox accessible to all staff is not an alternative.

Separate the enquiry, contact, review result, matter and document. The same contact does not imply identical access rights to all their matters. A repeat enquiry also follows the agreed route.

Describe transitions the form cannot decide

Instead of a single “new client” status, define a sequence: “received → initial review → awaiting internal check → responsible person's decision → invitation to the next step → handed over for matter handling”. Separate exits are “clarification needed”, “declined” and “closed without proceeding”. Labels can change, but every transition needs a condition, an actor and a recorded result.

Automation can create tasks and reminders and suggest matches within permitted data, but it must not declare that no conflict of interest exists. Store an authorised person's decision separately from delivery status. Finding no match is not a substitute for a decision.

Appoint a queue owner and a deputy. A reminder should contain the enquiry number and a link for an authorised employee, not the circumstances of the matter in a shared chat. Define the conditions for reopening a closed enquiry.

Test access boundaries for both the action and the object

CRM access control starts with a matrix: “role → specific enquiry → field → action”. A “lawyer” role should not, by itself, unlock every document in the firm. Add assignment context: is the employee part of this matter's team, and does that assignment still apply after a transfer? The following is an example design matrix, not a universal policy for law firms.

Separate viewing, editing, downloading, exporting and changing permissions. Viewing a record does not authorise exporting the database. For temporary administrator access, agree the reason, scope, end point and logging.

A hidden button does not protect a document

The OWASP authorisation guidance describes denying access by default and validating permissions on every request to a specific resource. Restrictions therefore belong on the server, not just in menus. Test direct file URLs, APIs, search, previews and exports. A long random link does not replace authorisation.

Before estimating the work, test the chosen CRM's restrictions with test accounts on the required plan and configuration. If it cannot separate fields, attachments or exports, reduce the data it holds or move documents into a separate protected environment. This is an architectural choice, not a CRM ranking.

Transfer minimum data and distinguish delivery from a decision

Website-to-CRM integration should create a traceable enquiry without distributing its contents across every service. Map what the website stores, what the CRM receives, where documents reside, which fields the email service sees and what reaches analytics. Also inspect webhooks, error messages and session-recording tools: they can become unnoticed copies of entered text.

Use the identifier, time and processing result for acknowledgements. Send analytics the agreed fact that a stage was completed, without descriptions, contact details or party names. Send the employee a link with permission checks, not the document.

For CRM outages, provide a controlled queue, limited retries and someone responsible for errors. Redelivering the same enquiry must not create new matters or broaden access. Before a manual retry, reconcile the identifier with the actual CRM record. Show the client an honest acknowledgement that the website received the enquiry, not that a lawyer successfully reviewed it.

Unlike a one-off corporate website acceptance check, this requires ongoing access control. The related article about transitions from an application to a permitted operation explains responsibility for transitions, not legal working procedures.

Attachments and logs must not create a back door

For documents, define permitted types and sizes, format validation and handling of suspicious files. Do not trust an extension or Content-Type alone. Storage must be non-public and retrieval subject to permission checks. Random names and antivirus software do not guarantee safety.

Until an attachment has been checked, do not make it available to the team as a regular document. Sending it to a third-party scanning service is also a data transfer: agree this separately and do not send confidential materials to a public analyser. After a team change, check permissions in storage, previews and cached responses, not just in the CRM.

Record the event, not the matter's contents

A log needs the actor, time, object, action and result: assignment, permission change, download or denied access. Do not copy full questionnaires, documents, passwords or tokens into it. Restrict access to the log too. Agree retention periods for enquiries, files, logs and backups separately; deleting a record does not mean all its copies disappear immediately.

A hypothetical example: the enquiry stays in the queue, the document does not

A hypothetical scenario, not a GL.ua case study: the firm has a coordinator, a reviewer and two teams. A visitor leaves contact details and the general subject without documents. The website creates an enquiry identifier; the coordinator sees the contact and assigns the next step.

The authorised employee requests the agreed information through a controlled channel. Until a decision is recorded, neither working team receives materials. After the permitted transition, team A receives only the relevant enquiry and requested documents. Team B cannot see them through search, a direct link or export. The marketer receives a de-identified transition event without the person's name or a description of the issue.

Now add a complication: the CRM accepted the record, but its acknowledgement was lost. A retry finds the same identifier, does not create a second record and does not send the documents again. After reassignment from A to B, the previous access is revoked; previously issued links are checked separately. A local copy already downloaded cannot be revoked by changing a role. Internal policy must account for this limit of the technical model.

What to test before opening the form to visitors

Run acceptance checks using fictional test data, not real client documents. Each role needs a separate account. A positive test shows that an allowed action works; a negative test shows that the system really blocks a prohibited action.

1. Submit an enquiry and reconcile its identifier, fields, initial state and responsible person in the CRM.
2. Go through clarification, rejection and handover. Try moving forward without the required human decision.
3. Under each role, open someone else's enquiry, a direct attachment URL, search and export. Check that access is denied without leaking fragments of data.
4. Reassign the team and block an employee. Repeat requests using the old session and previously issued links.
5. Simulate a CRM failure and a lost acknowledgement. Check retries, the absence of duplicates and whether the responsible person can see the error.
6. Review emails, analytics, logs and backup restoration in a test environment. Check which data remains and who has access.

Keep the results and unresolved limitations. A URL leak or handover without a decision blocks launch of that scenario. Attachments can be temporarily disabled if an agreed, working alternative channel exists; hiding the button is not enough.

Timing, costs and the boundaries of the first launch

Duration depends on agreement on the data and role model, the existing CRM's capabilities, access to a test environment and the scope of negative testing. A practical sequence is: data and transition map → permission prototype → integration → failure testing → training and pilot. Do not estimate a launch date solely from the readiness of the form design: unresolved export permissions may change the architecture.

Separate process analysis, role configuration, server-side integration, storage and file checks, logging, testing and training in the estimate. Account separately for licences, infrastructure, backups, monitoring and ongoing support. Costs also depend on whether old copies need cleaning up and overly broad access needs redesigning; a universal price without this breakdown tells you little.

The first launch can be limited to a form without attachments and manual approval. Do not automate the entire cycle before defining responsibilities and rules. The goal is a clear route with testable access boundaries, not more collected data.

For a discussion with GL.ua (Glyanec), prepare a state map, role matrix and de-identified enquiry example. Visit the business website development service to discuss the form, CRM and document-access flow, not the automation of legal decisions.