+91-8727000867
+64 22 003 5555
Legal Matter Update: A Technical Walkthrough
Follow one sample matter from internal draft to client update, then test what happens when its notification fails.
The planning answer
A saved staff draft, a published client update and a notification are three separate states. In our browser prototype, saving leaves the client view unchanged; publishing updates it; a simulated notification failure leaves the published update available. Retrying changes the notification status without changing the update. These interactions were checked on 20 October 2026 using fictional matter DEMO-104.
This walkthrough reports checks of the public Digittrix prototype and inspection of its JavaScript. Its sample data and delivery messages are simulated. The proposed production checks below have not been run against a deployed client portal. NSA Law is a separate, publicly attributed website project.
Open the example and establish the starting state
Open the matter-update prototype linked under Technical references, then choose Reset demo. The example identifies its record as “Sample matter DEMO-104 · Consultation request”. The staff and client panels share one browser page; they are not separate authenticated accounts.
The client panel starts with “Request received. The team will review your enquiry.” There is no unpublished draft or new notification, and Approve & publish to client is disabled. Only preset updates are available; do not enter real client or matter information.
Reproduce the browser checks
The following results were observed in the live prototype on 20 October 2026. “Delivered” below refers to a simulated UI status, not an email, SMS or provider receipt.
| Action | Observed result | What the check establishes |
|---|---|---|
| Reset demo | Original client message; no draft or notification; publish disabled | A repeatable starting state |
| Choose Consultation scheduled, then Save internal draft | Draft appears in staff panel; client message stays unchanged | Saving does not publish |
| Approve & publish to client | Client panel shows Consultation scheduled; draft clears; simulated delivery appears | Publication moves the saved draft into the client view |
| Choose Document review complete, then save again | Client still sees Consultation scheduled | A later draft does not overwrite the published update |
| Enable simulated failure, then publish | Client sees Document review complete; failed notification status and retry button appear | Notification failure does not discard the published update |
| Retry sample notification | Status changes to delivered after retry; client update stays the same | Retry changes delivery status independently |
| Reset demo again | Starting message restored; draft cleared; publish disabled | The example can be replayed |
How the current prototype implements the workflow
The public legal-page.js file binds controls inside the data-legal-demo element. A draft variable starts as null. Save copies the selected preset into that variable, writes the staff draft text and enables the publish button. It does not write to the client panel.
Publish returns immediately if no draft exists. Otherwise it writes the saved draft into the client panel, clears the draft and disables publication. The failure checkbox selects a simulated delivery or failure message and controls whether the retry button is visible.
Retry changes the notification message and hides its button; it does not rewrite the published client update. Reset clears the sample state. Activity messages are inserted as text, with the visible list limited to five recent entries after actions. This list is a demonstration aid, not a durable audit trail.
The demo handler keeps its state in the browser and does not call a notification service or persist a matter record. The page can contain unrelated site scripts. This source inspection does not establish backend permissions, storage security, real delivery, or production reliability.
What changes for a production client portal
The following is a proposed engineering design, not a description of NSA Law or a delivered Digittrix portal. A production system would need authenticated users, server-side authorization, durable records and independently recorded delivery attempts. Hiding a draft in this shared browser page is not access control.
Authorize each read and write against the user, firm, matter assignment and requested action. Deny access when no rule permits it. OWASP’s authorization guidance recommends checking permissions on every request; a disabled button cannot enforce that boundary.
Keep a draft revision, an approved publication and notification attempts as distinct records. Record the approving actor and revision. Reject a stale approval if the draft changed. Commit publication before reporting success and queue delivery against the published revision. Repeated clicks and retried jobs should not create duplicate publications.
A provider accepting a message, reporting delivery and the client reading an update are different events. Define those states in the provider integration and keep a failed notification recoverable without rolling back the approved matter update.
Record security-relevant events with an actor, action, record reference, timestamp and outcome. Restrict log access and avoid placing confidential matter text, tokens or credentials in general logs. OWASP’s logging guidance supports these controls; retention and legal obligations need separate project-specific review.
Acceptance checks still required before production
These are proposed checks, not passed test results. Run them in an authorized test environment with synthetic records before accepting a production implementation.
| Scenario | Required evidence |
|---|---|
| Another client or unassigned staff member requests a matter | Server denies access and returns no confidential record content |
| A reviewer publishes a draft that has since changed | Approval is rejected or requires review of the new revision |
| The same approval or job is submitted twice | One publication and controlled, traceable delivery attempts |
| Notification provider times out after receiving a request | Reconciliation and retry policy prevent uncontrolled duplicate sends |
| A staff member loses access | Subsequent reads and publication attempts are denied |
| The browser closes or the service restarts | Committed publication survives; unfinished delivery remains recoverable |
| Support investigates a failed notification | Authorized staff can trace the attempt without exposing confidential matter content |
Keep delivered website evidence separate
NSA Law’s public footer credits Digittrix for website design and development. Our case study records a homepage-to-Civil-Law deep link, keyboard opening and closing of the practice section, consultation-page fields and a 390-pixel mobile layout check. Those are observable website results.
NSA Law is not presented as the owner of this prototype, a client portal, a legal mobile app or the production design above. We have not published a client testimonial, enquiry-delivery result, backend security assessment or business uplift for that website.
Use the walkthrough in a scope discussion
For a Mohali law firm, start with one approved client-update journey and an anonymized example. Agree who may draft, approve and receive updates, which languages are needed, and what staff should do after a failed notification. Decide whether the current practice software can meet those needs before commissioning a separate portal.
Request an INR quote against the agreed scope and acceptance checks. For Digittrix custom legal projects, the client owns the custom source code and receives six months of technical support; the proposal records the support start date, inclusions and exclusions. Third-party licences, provider usage and hosting need explicit treatment.
Technical references
Checked on 20 October 2026. The prototype and its public JavaScript support the observed behaviour below. NSA Law supports the separate website case study. OWASP supports the authorization and logging guidance, not a certification of this prototype or any client system.
Continue planning
- Legal Document Workflows: Permissions, Versions & Approval
- Legal Data Migration: Mapping, Reconciliation & Cutover
- Legal AI Evaluation: Sources, Citations & Human Review
- Legal Software: Buy, Configure, Integrate or Build?
- Legal Software Integrations for Indian Law Firms
- Legal website and app development services
- Legal development in Mohali: local discovery, INR quotes and delivery evidence
Bring your workflow, existing tools and an anonymized sample to a scope discussion. Deliverables, pricing and dates are confirmed in a written proposal.
Request a Quote