142 parts, and what each one is for.

Getting into the app, and the age gate that decides whether an account may be used at all.

• Splash and first-run routing, so a returning user lands where they left off
• Registration and sign-in against the gateway, with tokens held in secure storage
• Password reset by email
• The 18+ age gate, presented before anything can be bought

The check that lets somebody transact, including the states a person sits in while a human reviews what the automatic step could not settle.

• Guided introduction explaining what is being asked for and why
• Face scan capture, and document check as the alternative path
• Borderline result and under-review states, so the person is never left guessing
• Verification status carried through to what the account is allowed to do

The first tab. A ranked feed of articles, videos and updates, plus the publishers behind them.

• A ranked content feed served by the gateway
• Content detail with images and rich text
• Publisher profiles, so a reader can follow a source

Self-guided tools: assessments a person takes themselves, their results, and the partner features built around them.

• Take an assessment, and read the results
• The delights map — a personal view, and a shared one
• Add, join, invite and compare partners
• Partner detail, so a comparison is readable rather than a score

The directory as a client meets it: browsing, comparing, saving, asking, and the chat that follows.

• Browse and filter the directory of professionals
• A profile with qualifications, languages, services and reviews
• Saved professionals — My Experts
• Chat with a professional, and the list of those conversations
• Consultation requests, for a question that is not yet a booking

What can actually be booked, with the price, the duration and whether it is online or on the premises.

• Browse services offered across the clinic
• Service detail with price, duration and delivery mode
• Straight into booking or purchase from the service

Buying — a single session, a package, or a product. This is where the credit a client later spends comes from.

• Product catalogue and product detail
• Cart, checkout and the service agreement accepted at purchase
• Order confirmation, and the order history behind it
• Payment handled by the gateway, never by the app

Spending a credit on a specific time in a specific diary — and everything the client sees about it afterwards.

• Create a booking against real availability, in the client’s own timezone
• The bookings list, with every status a session can have
• Booking detail: join link, location and room, reschedule and cancel
• Purchased sessions — credits owned, spent, and still to book

Asking in public, asking in private, and the people a client chooses to share progress with.

• A public question feed, and asking a question before committing to anything
• Question detail with the professional’s own answer
• Support tickets — raise one, track it, read the replies
• Partner invitations and the partner list

The third tab, and the answer to most support questions. Everything the app knows about the person, on one screen.

• Booked meetings and meeting history, with feedback and session reviews
• Credits, purchased sessions and favourites
• Billing address, invoices, invoice detail, payment methods
• Notifications, chats with professionals, partner chats and questions asked
• My services and my content, for people who publish
• Edit profile, change password, and the account screens

The same tab, seen by a practitioner. This is what makes a whole practice runnable from a phone rather than from a desk.

• Availability: weekly hours, and dated schedule exceptions
• Clients’ chats, and the client history behind each conversation
• Submit a session report from the session it belongs to
• Expert analytics — the booking funnel, lead time and per-client figures
• Earnings and the four buckets, hidden and replaced by counts on a salaried contract

A conversational assistant in the app, streamed through the gateway so no model credential ever reaches the device.

• A chat screen with streamed responses
• Conversation history, so a thread can be picked up later
• Routed through the gateway’s AI interface, which resolves to a real provider or a mock

The controls a person expects to find, including the ones a regulator expects them to be able to find.

• App settings and language selection across 23 locales
• Privacy settings, and which notifications arrive on which channel
• Security settings, including device sessions
• Terms, privacy policy and legal documents in the app rather than on a website
• Account deletion, as a route the person can take themselves

What every feature above is built on. Not a screen, but the reason the screens behave consistently.

• Networking against the gateway, with token refresh and error handling in one place
• Secure storage for tokens and secure device state
• Routing, so a notification can open the exact screen it refers to
• A single theme carrying the Raznameh design system
• 23 translation files, with the calendar system following the person, not the business
• Shared widgets, so a list, an empty state and an error look the same everywhere

Brokers login against the business core and issues short-lived tokens of its own. The app never holds a core credential.

• Sign in, sign up, refresh and sign out, with JWT issued by the gateway
• The current user and their profile
• Device registration, so push notifications reach the right handset
• Legal documents and the acceptance recorded against a person

Everything a client browses before they spend anything, served fast and cached where it is expensive.

• Professionals, their profiles, availability and services
• Service categories and bookable products
• Reviews and ratings, with moderation state respected
• Cached reads for anything the directory hits repeatedly

The transactional half. Purchase, credit, booking, invoice and payment, each mapped onto the business core rather than reimplemented.

• Create, reschedule and cancel a booking, with the policy applied by the core
• Orders and the credits they produce
• Invoices and invoice documents
• Payment initiation and confirmation, behind a payments interface

The read-heavy half: what a person browses when they are not booking.

• The ranked content feed and content detail
• Public questions and answers
• Discovery, assessments and their results
• Partner features and the comparisons built on them

The WebSocket hub. Chat, presence, AI streaming and signalling for voice and video, on one connection.

• WebSocket connection management and presence
• Chat between client and professional, and group channels
• Signalling for voice and video calls
• Notification delivery and per-person notification settings
• Push notifications through Firebase Cloud Messaging

Files, held so that the app never talks to storage directly and nothing is served from a guessable URL.

• Secure document access, honouring the core’s access rules rather than re-deciding them
• Media upload and retrieval, proxied through the gateway
• Images resized and cached, so a directory listing is cheap on a phone

The remainder: raising a ticket, asking for a consultation, telling the app what this deployment has switched on, and talking to a model.

• Support tickets and their replies
• Consultation requests
• Runtime configuration, so the app shows only the features this business enabled
• AI requests, streamed, with the model credential held here and nowhere else

Four feature flags, each resolving to a real provider or a mock. It is why the estate can be demonstrated, developed and tested with no external account at all.

• DATA_SOURCE — the Odoo business core, or a mock dataset
• PAYMENTS — a real provider, or a mock that behaves like one
• NOTIFICATIONS — Firebase Cloud Messaging, or a mock
• AI — a real model provider, or a mock
• Rate limiting and token buckets in Redis, so a limit holds across workers
• No single external vendor can stop the clinic from selling, delivering and recording a session

The scheduling engine underneath everything else — calendars, availability, rooms and the rules that decide which slots a client is actually allowed to see.

• An availability engine that resolves weekly hours, dated exceptions and existing bookings into free slots
• Schedulers, hosts, locations and rooms, with capacity and clash detection
• Slot rules, waitlists and automatic slot offers when a booking is freed
• Intake questions asked at the point of booking, with the answers kept on the booking
• Reminders by email and SMS, with per-person suppression lists
• Calendar publishing as ICS, and links into external calendar systems
• Attendance records, a booking funnel and analytics behind the per-expert figures
• Rate limiting on public booking routes, and an erasure path for booking data

Sells one-to-one sessions as credits. This is the module that makes buying and booking two separate steps, which is what allows a package to be sold today and scheduled over months.

• Sessions sold as credits against a product, singly or as a package
• Package service agreements accepted at purchase and kept at the version accepted
• Tiered cancellation policies with notice windows, penalties and a grace period
• Reschedule and cancellation flows that return the credit where the policy says so
• The expert buckets — bought, booked, held, not booked — and per-expert progress
• Portal booking links, and website cart gates that stop an unbookable purchase
• A pay resolver seam: the session freezes its own split at booking without knowing what a contract is
• Post-session feedback, and the no-show trail that reliability reporting needs

The application layer: professionals and their public profiles, the mobile API, content and community, notifications, and the client-facing account.

• Expert profiles with a verification workflow, credentials, services and calendars
• Reviews, ratings, public questions and the expert dashboard behind them
• REST endpoints for the mobile app, JWT authentication, and WebSocket sessions
• Realtime chat — client to professional, partner chats and group channels — bridged onto sessions
• Content and publishing: publisher profiles, a ranked feed and discovery
• Invoices, payment methods and the order-to-session bridge
• Notifications across push, email and in-app, with a fan-out for session alarms
• Age and identity verification, support tickets, consultation requests and device registration

Odoo appsOnDelights Platform

The seventeen management reports. Twelve ask whether the clinic’s record matches what happened; four compare how professionals are doing; one sits above them all.

• Alignment lists: stuck sessions, unbooked credits, coverage vs demand, money chain, fee ledger
• Payout readiness, cancellation conduct, compliance file, client continuity and the moderation queue
• Sessions without a report, and cancelled sessions read alongside conduct
• Performance: the expert scorecard, the league table, reliability and client outcomes
• One scope control — whole business, selected people, one person — with a comparison period
• Saved views and CSV export on every report
• A report never writes: uninstalling removes the reports and changes no operational behaviour

The clinical note a professional files after a held session — stored as a secure document about the client rather than as an attachment on a meeting.

• A report filed against the session and recorded as being about the client
• Encrypted at rest on the secure document service, with a key per version
• Access decided only by the care team resolution, never by a role or by seniority
• Corrections filed as new versions; the previous version stays exactly as it was
• Every read logged, so chasing a missing report never means reading one

A standing arrangement rather than a purchase each time: a plan sold in the shop, and one client’s membership against it.

• Plans are shop products with an image and a description; the public catalogue is at /memberships
• A membership carries session credits, chat access and offline consultation minutes
• Credits stay ordinary session credits, so booking never learns a second rulebook
• Periods with renewal and rollover, and what rolls over decided by the plan
• An expert sees which of their clients are members, and on what

Expert time bought as minutes rather than as an appointment, spent in chat and accounted for to the minute.

• A service can sell a budget of expert minutes, with an optional validity window
• Rate card on the company, overridable per service
• A ledger entry per charge, and a statement both the client and the expert can open
• The budget is checked where the message is sent, not where somebody remembers to check it

The questionnaire a client fills before the first session, stored as clinical content rather than as survey answers.

• A service names the questionnaire that goes with it
• The client fills it before the session, from their own pages
• Answers are written straight to an encrypted document — never left in the survey’s own storage
• The clinician opens it from the session, under the ordinary document access rules

Bank transfer as a payment route, for clinics that want a person to look at every order before and after the money moves.

• Approve the order, invoice it, take the proof of transfer, approve the proof, then mint the credits
• Credits appear only once the proof is approved, so an unpaid order cannot book a session
• A rejection carries its reason, and the order goes back to the person who can fix it
• Every step is a state on the order rather than a note somebody left

The client-facing half of the offline route: where they pay, what they upload, and what the order is waiting for.

• Each state has its own colour and mark on My orders, so waiting is visibly different from rejected
• Pay and upload the proof in one dialog, without leaving the order
• The rejection reason is shown where the person who has to act on it will read it
• A dashboard card for orders that need something from the client

The books, on a dashboard of their own: what came in, what is owed, what delivery cost and what is still to come. Separate from the administrator's by design — chasing an unpaid invoice on the floor is one job, and keeping the ledger is another.

• A landing page of four money tiles, six health ratios, six charts and a flag list
• Twenty-one reports: cash, revenue, delivery cost, forecast, leakage and two control checklists
• Accrual or cash, five periods and a custom range, carried through every drill-down
• Narrow any report by service, expert or client; a graph view and CSV on every page
• Nothing netted, no rate without a denominator, forecast layers never summed
• A month-end close checklist where all ticks is the good close
• Reads the ledger and never clinical content — a separate grant, on an internal account

What needs doing, for the four teams around the clinic. Sales, people, marketing and delivery each get a page, and every page opens with the same question: what is late, what is now, what is coming, and what has nobody promised to act on.

• Four dashboards, each a record rather than code, so a pack can add one
• The activity strip on every page: late · today · planned · nothing scheduled · needs attention
• **Nothing scheduled** is the band Odoo has no state for — an open record nobody has promised to do anything about, which appears on no other screen
• The attention rule is printed under its own count, because a threshold the reader cannot see is one they stop trusting
• Twenty-six reports, each carrying the code of the specification row it implements
• A figure whose model is not installed reports *not applicable*, never zero
• Lists that should be empty, with a nightly alert that ships switched off
• Every rate prints its denominator, and an em dash under five records
• Today's presence and absence — still checked in, checked in today, on leave today
• Depends on base, mail and web and nothing else: it reports on CRM, HR, mailing, project and contract data without requiring any of it

How we are doing, in the app managers already open. Four pages in Odoo's own Dashboards, in a Clinic Teams section of their own, built the way its Sales and Expenses pages are built.

• Four pages — CRM, Sales, Delivery, People — beside Odoo's own
• Four KPI tiles a page, each with the previous period beside it
• Two charts and two to four top-N tables a page, every one opening the records behind it
• A figure that is a state of the world takes no period and shows no comparison — headcount filtered to the last ninety days is not headcount
• A chart grouped by a date takes the period; one grouped by a stage does not
• The workbooks are generated and their cross-references validated before anything is written
• Each page is visible to the Odoo group that owns its data, so nothing extra is granted

Three more pages in the same section, kept apart because each one needs an app the clinic may not run.

• Attendance: currently checked in, records, hours worked, extra hours, by employee and by department
• Time off: requests awaiting an answer, days approved, refusals, and where leave falls by month, type and department
• Staff payments: to report, to validate, to reimburse, and what was claimed in the period
• Separate from the other dashboards because each forces an app — attendance, time off, expenses
• Attendance counts records, not people: a lunch break makes one person two rows, and the page says so
• Currently checked in is a presence figure during the working day and a list of people who forgot to check out after it

A public form that turns a question into a task somebody owns.

• A form at /support/ticket that anyone can use, signed in or not
• Each submission opens a task, assigned to the store administrator
• The submitter follows their own ticket, and the administrator is notified in Discuss

A course of care with a start, an end and a plan — the spine everything else in the clinical record hangs from. Care is not a stream of appointments, and the record says so.

• An episode opens on the first held session, and a client has one open at a time
• A treatment plan per episode: problem → goal → objective, three levels and no more
• A goal carries a title, a target date and a result — what was worked towards, and how it went
• Running or Finished as the client-safe state, kept apart from the six clinical outcomes so the two never share a screen
• A plan is reviewed or superseded, never edited in place: the version that was agreed stays as it was
• Closing an episode asks for an outcome on every open goal, because that is the only moment anyone knows the answer — and says how many would close without one
• Closure starts the retention clock the document service counts from
• Every expert who has met the client sees the episode; reading a colleague’s report is a separate request, approved by a clinic administrator and written to the log either way
• The client reads the same episode on their own pages, in words that never grade them

Note templates as an ordered list of typed fields, so a note is answers rather than prose nobody can search.

• A template is a versioned, published list of typed fields — text, number, scale, choice, date
• A completed note is the answers plus a rendered secure document
• Answers are readable exactly when their document is: one access rule, not two that drift apart
• Visibility per field, so a private observation is absent from the client’s copy rather than hidden in it
• Templates chosen on the session report form, by discipline

The starting content for the template engine: a thousand named note formats, so a clinic does not begin with an empty library.

• Over a thousand named templates — SOAP, DAP, BIRP, intake, review — grouped by discipline
• Installed as data, editable afterwards like any template the clinic writes itself

What a client records between sessions, attached to the goal it measures. A programme that reports against nothing is how monitoring turns into homework.

• A programme library with six item kinds: questionnaire, measurement, choice, journal, upload, task
• A programme is sent to a goal, so every entry reports against something the plan actually asked for
• The client records on their own plan: what is due today first, then each goal and what is open against it
• Nothing on a client surface counts or rates them — a thing not recorded reads as not recorded, and there is no rate, no score and no streak
• The clinician’s caseload worst-first: risk flags to acknowledge, never started, silent over fourteen days, ending this week
• A rate with fewer than five to measure renders as a dash, and a count that failed renders as unavailable — never as nought
• “I’m finding this hard”, which reaches the clinician without a number attached to it
• Reports filed on a goal rather than on an appointment, encrypted, under the same access rules as every other clinical report
• Programmes reviewed at a session, counted by the clinic report that asks whether anyone looked
• Every surface carrying observations says that entries are not monitored in real time

Clinic-owned scored instruments. No instrument content is shipped and no licence is claimed: the clinic enters what it is entitled to use.

• A score is stored with the instrument version that produced it, and is never recomputed
• Bands and thresholds per instrument, with a risk band raising a flag somebody has to acknowledge
• Filled by the client on the portal or in session, and the channel recorded either way
• Per-instrument timelines with direction; scores from different instruments are never combined into one number, because they measure different things on different scales
• A questionnaire is a kind of programme item, not a separate feature with its own list

One note written once and filed to each attendee as their own document.

• One authored source, one filed document per attending client
• A private field is absent from another attendee’s document, not hidden inside it
• Filed to the people who attended, not to everybody who was booked
• The session counts as documented only when every attendee has their copy

A due date a clinician sets when a session ends, acted on when it arrives.

• A recall is a date and a reason, created at the end of a session
• It invites; it never books
• Due recalls appear on the clinic digest before any message is sent automatically
• Automatic invitation stays off unless the clinic switches it on

Diagnostic codes where the billing needs them, searchable rather than typed from memory.

• Searchable ICD-10-CM chapters and codes
• A code recorded on the client and carried onto orders and invoices

Session pay terms on the employee contract, and the payment cycle that settles them. Nothing is recomputed at payout time — each session froze its own split when it was booked.

• Four pay types: monthly salary, hourly rate, fixed fee per session, or a percentage of each session
• Terms held on the contract version, so the history is dated and one is in force at a time
• Payment cycles — weekly, fortnightly, monthly or quarterly — anchored on the calendar or the contract start
• A daily job that opens a draft payout run the morning a cycle closes
• Confirming a run raises one vendor bill per professional from the frozen amounts
• A kept payout history the professional can see, including cancelled runs
• Renegotiating today never rewrites what was owed last month

Sends engagement contracts for signature from the record they belong to, and keeps the signed history on that record.

• Send a contract for signature from the contract itself
• Every request kept against that record as its history
• Session pay can be withheld under a contract nobody has signed yet
• Installs itself only when both sides are present, so neither module carries a dependency it does not need

The service itself. A model adopts it in one line and gains its documents, a count, and a filing dialog that says in plain language who will be able to open the result before it is stored.

• Encrypted at rest with a key of its own, stored outside the Odoo filestore and never served through /web/content
• Access by explicit rules, default deny: a matching allow rule and no matching deny rule, every time
• Being an administrator, a manager, or the person who filed it grants nothing by itself
• Every read as well as every write logged, in a hash-chained append-only log nobody can edit
• Versioned and append-only: a correction is a new version, the previous one is untouched
• Retention and disposal under relative rules, carried out by destroying the key
• Deliberately does not search inside documents — encrypted content cannot be full-text searched

The cryptographic layer, kept as a module of its own so key management can be reviewed and audited without reading the rest of the application.

• AES-256-GCM envelope encryption: a random data key per document version, wrapped under a deployment key
• The key encryption key is never stored in the database
• Ciphertext in a directory of its own, outside the filestore
• Key rotation that re-wraps keys without rewriting a byte of ciphertext
• Crypto-shredding: destroying the key disposes of the document and leaves the audit trail intact
• Refuses to start if the key is missing, world readable, owned by the wrong user, or stored where it would travel with the data

Where a person reads the documents that have been shared with them about themselves, at /my/documents — and only those.

• A subject sees a document when a subject access rule grants it and nothing denies it — never merely because it is about them
• Psychotherapy notes, sealed documents and documents under a current withholding decision are never shown, whatever their rules say
• One filter used by every route, so there is only ever one definition of who may see what
• Content decrypted in memory and streamed; nothing written to disk
• A document the user may not see returns 404, never 403 — guessing references must not reveal who holds records
• Every view and download logged, including the subject’s own, and the page says so
• Reads rate limited per user, counted from the access log so the limit holds across workers

Files secure documents against contacts — the commonest subject, since the person a document is about is usually the person it is filed against.

• Adds the secure document service to res.partner
• Installs itself once both sides are present, and uninstalls without touching either
• A bridge per application, so adopting the service on a contact does not pull in unrelated apps

Files secure documents against opportunities — a due-diligence pack is nothing clinical, and has exactly the same requirements.

• Adds the secure document service to crm.lead
• Encrypted, rule-gated and logged on every read, like any other secure document
• Installs and uninstalls cleanly and independently of the other bridges

Files secure documents against employee records — a disciplinary file or an occupational health report is something a manager files and most of HR must not be able to open.

• Adds the secure document service to hr.employee
• Default-deny access, so an HR role does not open a file by virtue of being an HR role
• Installs and uninstalls cleanly and independently of the other bridges

Files secure documents against tasks — a confidential contract or a signed deliverable held where the work is tracked.

• Adds the secure document service to project.task
• Installs itself once both sides are present, and uninstalls without touching either

Files secure documents against orders — a signed agreement, or a customer’s identity documents, held against the sale they belong to.

• Adds the secure document service to sale.order
• Installs itself once both sides are present, and uninstalls without touching either

Optional: move the key-encryption key off the Odoo host, so a copy of the database is not a copy of the documents.

• Document keys wrapped and unwrapped through a remote authority rather than locally
• The key-encryption key never sits on the machine serving the application
• Switched on per deployment; the local backend stays available and unchanged
• An authority that is unreachable refuses to open documents rather than falling back quietly

Resolves the care team. A therapist reaches the records of the people on their own caseload, not the clinic’s — which is what makes the minimum-necessary standard enforceable rather than aspirational.

• Care relationships — clinician to client, with a kind, a start and an end
• Access ends when the relationship does, after a grace period long enough to finish outstanding notes
• Clinical roles that decide what part of the application someone reaches, never what they can open
• A director-only profile for incidents, complaints and safeguarding referrals — closed even to whoever filed them
• The disclosure register: what left the service, to whom, and on what basis
• Subject rights: access requests with their statutory clock, amendments that append rather than overwrite, restrictions that seal
• Retention anchors — last contact, date of birth, date of death — for the base layer to compute against
• The breach record itself — what happened, who was affected, and whether whoever took it could read it — with the jurisdiction layers adding their own clocks to one incident rather than each keeping its own
• Confidential communications: a client can ask that a channel is never used, and it is refused where messages leave rather than where somebody remembers — email to a blocked address is cancelled, never quietly sent to the address on file
• No field anywhere to record why they asked, because requiring an explanation is what the rule forbids
• One extension on an access request and only one, capped against the resulting date rather than the number typed — a month from March and a month from July are not the same length
• The fee itemised into the components the regulation permits, because "reasonable, cost-based" is a claim and a claim with one number behind it is one nobody can check
• A copy to someone the individual named, refused until their signed written direction is on file
• A refusal reviewed by somebody other than whoever refused — enforced, not left to procedure
• A denied amendment the person disagrees with: their statement, any rebuttal, and both travelling with every later disclosure of the disputed record — attached by the register, not by anyone remembering
• Whoever downstream already has the information named and told, because an amendment nobody hears about corrects one copy of a record

The GDPR layer: the rights and governance machinery HIPAA has no equivalent for, which is why a US-standard build does not cover the EU.

• Lawful basis recorded per document type — Art. 9(2)(h) for treatment records, not consent
• Erasure (Art. 17) carried out by destroying the key, so the right is honoured without erasing the evidence of what was held
• An erasure assessment, and nothing destroyed while a legal hold or retention period stands
• Portability (Art. 20) as a streamed zip — metadata as JSON, content as filed, every document logged individually
• Breach notification (Art. 33/34): 72 hours to the authority, and the encryption exemption under Art. 34(3)(a)
• DPIA and ROPA records kept as part of the governance file

A bridge, not a build — joins a signed privacy notice to the acknowledgement record, so the file can answer which version they actually saw.

• A completed signature writes the acknowledgement, once — a webhook delivered twice must not make the count of who is outstanding wrong
• The signature request names the notice version, because that is the only question an acknowledgement gets asked
• A pen on a form at reception is still a written acknowledgement; the bridge adds a path rather than replacing the ordinary one
• A request signed by a clinician on a client’s behalf is not that client’s acknowledgement, and is not counted as one

UK GDPR and the Data Protection Act 2018 on the same technical core — with the serious harm test built as a workflow rather than as a flag.

• The serious harm test (DPA 2018 Sch. 3 Pt. 2) recorded with who decided, when, over which documents and why
• Only takeable by someone holding a current care relationship, which the system checks rather than assumes
• Appears in a review queue before it expires, and lapses on its own at six months
• Lifting it restores the label the document had before, not "normal"
• Withholding is from the subject, not from the care team — the people treating the person still read it
• The NHS Records Management Code of Practice 2021 retention schedule as seed data
• Access to Health Records Act handling for the records of the deceased

The administrative safeguards — the half of HIPAA that is not about encryption, and the half enforcement cites most.

• The risk analysis as an exercise with a period, a scope and a method, separate from the register of what it found — so next year can be compared with this one
• Each risk carried into the next assessment with a link back, because a register that starts blank every year loses the record of what was decided
• The inherent rating computed and the residual rating deliberately not — a residual worked out by subtracting a control score is a fiction that says the same thing about a control tested last week and one written in a policy
• Accepting a risk requires a recorded reason; the decision is often right and nobody can tell afterwards which it was
• The activity review with its questions named — no care relationship, break-glass, a shared surname, out of hours, a volume outlier — because "review the logs" without saying what to look for is how reviews become a signature on nothing
• Completing a review verifies every hash chain touched in the period, which is what turns a tamper-evident log into a tamper-noticed one
• Designations held as date ranges with the gaps computed, because the requirement is not who holds it today but that somebody held it without a break
• Sanction records readable only by a group nobody joins by implication — a sanction record that leaks is its own incident
• A termination checklist and a daily job that raises one for anybody whose departure date has passed: accounts outliving employment is the control most often failed
• Training with an expiry, because training that expired is not training
• A criticality analysis that checks its own arithmetic: a system whose database recovers slower than it does has a recovery objective somebody wrote down, and the two numbers live on different rows in a spreadsheet
• Contingency plans that say when they were last tested, and a list of the ones that never were — the only thing telling an organisation with a plan apart from one that believes it has a plan
• A test that did not meet its objectives has to say what went wrong, because a test that taught nobody anything is not evidence
• Transmission security as a history rather than an assertion: "we use HTTPS" is about the present tense, and these records say it was true on the days somebody asks about
• Checks that cannot be edited or deleted, because the point of a history is that it cannot be tidied

The HIPAA layer. The separation of psychotherapy notes holds in the storage rather than resting on the access rules being right.

• The designated record set (45 CFR 164.501) marked per document type, so a subject access response cannot include what is out of it
• Psychotherapy notes in their own key namespace — the key that opens the ordinary record does not open them
• A subject grant on notes refused at every path, including a direct write to the rule table
• A document already written cannot be relabelled into the notes key space
• 42 CFR Part 2: the redisclosure prohibition notice generated rather than typed
• Six years of disclosures in the register, per the sub-part
• Breach notification (164 Subpart D): an impermissible disclosure is presumed a breach until the four-factor assessment says otherwise, with the reasoning recorded
• Sixty days to the individuals from discovery, computed rather than typed, and warned on before it runs out
• The two five-hundreds kept apart — media notice above 500 residents of a State, HHS notice at 500 or more in total
• Individual notices carrying all five elements 164.404(c) requires, so none can be quietly left out of a letter that reads well
• The annual log of small breaches produced as a document, not assembled from memory in February
• The Notice of Privacy Practices versioned, with acknowledgements recorded against the version somebody was actually given
• The half that is easy to skip: where no signature was obtained, the effort and the reason are required — a folder of signed forms cannot answer that question
• A work list of clients with nothing recorded against the notice in force
• The grounds for refusing access as a closed list, each carrying whether the individual gets a review of it — offering one that does not exist and refusing one that does are both findings
• The four grounds for denying an amendment, closed too, and the one that is a fact about the document checked against the document
• The 2024 Part 2 rule: one consent covering treatment, payment and operations, refused unless it is revocable — a single consent with no way back is the one somebody forgets they gave
• A Part 2 restriction on those purposes treated as a right rather than a request, and checked before the general one — a check that ran the other way round would permit the disclosure before reaching the question
• A breach involving substance use disorder records says so in the notice, rather than burying it under "treatment information"
• 164.410 as two clocks: the business associate has sixty days from its own discovery and ours start when they tell us, so a breach can be 118 days old with nobody having missed a deadline
• The Part 2 patient notice versioned beside the privacy notice, rather than a constant in Python nobody versions

The German retention period, as a rule the document service counts rather than a line in a policy nobody applies.

• § 630f BGB: ten years after last contact, seeded as a retention rule
• Scoped to this module rather than to the whole EU pack, because the period is national

The Norwegian rules the GDPR layer does not cover, each one sitting where the action happens rather than in a policy: publishing a profile, confirming a payout run, disclosing something to a parent.

• Pasientjournalforskriften § 14: the patient reads every access to every record about them, including the records they are not shown — by type, never by title
• A retention kind with no disposal date at all, because Norway keeps records while they are needed; the years are a review interval and a person decides, with a reason
• A journal hand-over to a successor, Norsk helsearkiv or Nasjonalarkivet, built at the moment of download, recorded as a disclosure per document, and downloadable once
• Helsepersonelloven § 74: a profile using a protected title cannot be published without a checked HPR number, and the check runs on write so the sync cannot get round it
• Nearest relative, parent, guardian and lasting power of attorney, with the §§ 3-4 and 4-3 age rules enforced at the disclosure register rather than as a filter on a page
• Arbeidsmiljøloven § 1-8: a payout run that pays per session will not confirm without a current determination, and the facts behind it are shown unweighted because the question is legal
• Personvernombud and information security lead as designations, checked for Norwegian companies only

The roles Finnish law makes a provider name, and the duties hanging off each one. Independent of the Norwegian pack — both switch on from the company country, so one database can hold both.

• Licensed and protected-title professionals kept apart, because they are different rights: psykoterapeutti is a protected title in Finland and a free word in Norway
• Terhikki number, the date of the employer check and whether it was a register lookup or the decision document; a typed number counts as declared, not checked
• A service unit with its own registration, and the vastuuhenkilö as a designation per unit, so a fortnight with nobody answering for it is reported
• The public self-monitoring plan and the confidential security plan kept apart by construction: one policy record cannot be flagged as both
• Asiakastietolaki § 11: two years of log information with the recipient and the basis, a written request with a two-month clock, and a withholding recorded with its reason
• Potilaslaki § 9(2) has no age, so a minor is a recorded judgement: without one, a disclosure to a guardian is refused and the refusal says the judgement is missing
• Twelve years after death, and where the death is not known, 120 years from birth

Switzerland splits the qualification from the permission to practise, counts insured sessions against a doctor's order, and binds the supplier to the same criminal secret as the practitioner. Three things the core cannot express, and nothing else.

• The federal title is not the licence: a practice permit is cantonal, one per canton, each with its own expiry, so a practitioner may hold the name in Switzerland and the right to work in only one place
• A profile using a protected title is refused publication without both a checked PsyReg number and a current, checked cantonal licence — and the refusal says which of the two is missing
• Where a title is checked and no licence is, the public status says so rather than implying one; an unverified market is not served by a listing that reads like a verified one
• Anordnungsmodell: fifteen sessions on a doctor's order, renewable once to thirty, and the insurer beyond that — counted through the chain of renewals, warned before the session that would not be paid for, and refused at the second renewal without an approval on file
• Only a delivered session counts; a booked one does not, because counting it would stop an order two sessions early
• Article 321 binds auxiliary persons to the same criminal duty as the practitioner, so the register asks the one question the article turns on: can they read the data in the clear?
• Ten years after the last contact, seeded on the retention clock the document service already had — no second way of saying the same thing
• The cantons each practitioner is licensed in decide which language their authorities correspond in, shown on the practitioner and on every licence
• Insured billing has its shape here and none of its catalogue: a tariff edition, positions in taxation points, point values per canton and insurer class. The positions and point values are licensed data a deployment loads, because a plausible invented code is one somebody bills on
• A session that cannot be priced says which canton has no point value loaded, and shows no amount at all — zero francs would mean the session costs nothing, which is a different statement
• German, French and Italian throughout the interface, in Swiss terms: a Berufsausübungsbewilligung rather than a translated "cantonal licence", and a Hilfsperson rather than an "auxiliary person"

A fixed list of questions asked of the deployment itself. Most of the checking already existed and was scattered; this is the page that reads it in one place.

• A registry of checks, a runner on a schedule, and a report over both
• Only what is wrong is reported: a check that passes says nothing, so the page is empty when the deployment is sound
• Each finding names the rule it came from and the record it was found on
• Runs are kept, so a finding that keeps coming back is visible as a pattern rather than as news

The signature service itself: a portal signing ceremony, jurisdiction policies, and a hash-chained audit trail. Self-hosted, so no document leaves the estate to be signed.

• A portal signing ceremony with identity and intent captured at the moment of signing
• A hash-chained audit trail nobody can edit or delete
• Jurisdiction policies governing what a valid signature requires
• Signature requests as records, with their own status and history

Who was empowered to sign for a counterparty, and whether their credential is still valid — checked rather than assumed.

• Authority to bind tracked per counterparty signatory
• Signed agreements kept as records with a term
• Practitioner credentials chased before they lapse

What a clinical signature needs beyond a name: capacity, authority to sign on somebody’s behalf, supervision, and consent that can be withdrawn.

• Capacity attestation recorded at the point of signing
• Signing on behalf of a client, with the authority recorded
• Supervisor co-signature where the service requires it
• A revocable consent lifecycle rather than a one-off tick

The elements HIPAA requires of an authorization, validated rather than trusted to a template.

• Validation of the required elements of a HIPAA authorization
• 42 CFR Part 2 material segregated from the rest
• The accounting of disclosures a covered entity must produce on request

A Request Signature action on applicants and employees, so an offer or a policy is signed where the person already is.

• Request Signature on an applicant record
• Request Signature on an employee record
• Requests kept against the record as its history

A Request Signature action on quotations and purchase orders.

• Request Signature on a sale order
• Request Signature on a purchase order
• The signed document kept against the order

Puts signature templates where the clinic sells: pinned to a professional or a service, sent automatically on purchase, and visible as a status.

• E-sign templates pinned to an expert or to a service
• Sent on purchase, without anybody remembering to send it
• Signed status shown to professionals in the portal and in the mobile app

Ends a session nobody is using. 45 CFR 164.312(a)(2)(iii) asks for termination after a predetermined period of inactivity, and leaves the period to you — so it is a setting, with the enforcement on the server rather than in the browser.

• Idle period, warning period and an absolute ceiling, set per company
• Checked on the server on every authenticated request, so switching off the browser timer buys nothing
• A warning before the session ends, so nobody loses a half-written note to a control meant to protect them
• An absolute ceiling as well as an idle one, because a session kept alive by a script is still a session that should end
• Every termination recorded — who, which surface, and which rule ended it
• The record is append-only: evidence that a control operated is worth what it costs to change it
• Set the period to zero to disable it, which is a decision the specification permits and your risk analysis records

Connects Odoo Community to any large language model, behind an interface — so the vendor can change without the business logic knowing.

• Providers configured per deployment, with the credential held outside the application code
• Agents defined as prompts with the tools they are allowed to call
• Tool calling, so a model can act rather than only answer
• Runs recorded, so what was asked and what came back is inspectable afterwards
• Server actions that can be driven from a prompt
• Diagnostics for checking a provider is reachable and configured correctly

Converting a user between internal and portal by hand means editing access rights in the right order and remembering the side effects. This makes it a button.

• A User Type field on the user form, the list and the search filters
• Convert to Internal and Convert to Portal buttons on the user form
• A Convert User Type action on the Users list, for several users at once
• Guard rails: the system user, your own user and the last remaining administrator can never be converted by accident

Companies, users, groups, contacts, languages and the record rules that decide who sees what. Not shown in the Apps list because everything depends on it.

• Companies and multi-company scoping
• Users, groups and record-level access rules
• Contacts as a single model shared by clients, professionals and suppliers
• Languages, translations and per-user locale
• Scheduled actions — the job queue behind every nightly task

The back-office interface staff work in, and the editing tools behind every rich-text field and website block.

• List, form, kanban, calendar, pivot and graph views
• Filters, groupings and saved searches on every screen
• Export to CSV and XLSX from any list
• HTML Editor — the rich-text field used across records
• HTML Builder — the drag-and-drop block editor
• Web Routing — the URL layer every portal and website page is served through

Odoo appsWebWeb RoutingHTML EditorHTML Builder

Messaging, and the message thread attached to every record — which is how a decision keeps its history instead of living in somebody’s inbox.

• The chatter on every record: messages, notes, followers and tracked field changes
• Internal channels and direct messages
• Outgoing email with templates, and inbound routing
• Activities — a to-do assigned against a record rather than to somebody’s memory
• OdooBot, and its HR variant for onboarding prompts

Odoo appsDiscussOdooBotOdooBot - HR

The authenticated area a client, a professional or a counterparty reaches without being an internal user — everything under /my.

• Portal users with no access to the back office
• Documents, orders and invoices shared with the person they belong to
• The frame every custom portal page in this platform is built inside
• A customised sign-up page, so registration matches the brand rather than Odoo’s default

Odoo appsCustomer PortalCustomize Signup Page

The address book application: people, organisations, and the relationships between them.

• Individuals and companies, with child contacts
• Addresses, tax identifiers and bank details
• Tags and categories used for segmentation
• The record a client, a professional and a supplier all resolve to

Odoo appsContacts

What is sold. In a clinic that is sessions and packages, but the model underneath is the standard one.

• Product templates and variants
• Units of measure, and service products for time
• Pricelists, so a package or a segment can be priced differently
• Product categories used for reporting by service line

Working calendars, capacity and leave — the model a professional’s weekly hours and dated exceptions are expressed in.

• Working schedules per person, with timezones
• Resource capacity and leaves
• The calendar utilisation is calculated against

Odoo appsResource

The small installed modules nobody opens on purpose, each of which removes a specific category of support ticket.

• Onboarding Toolbox — guided set-up progress for a new deployment
• Phone Numbers Validation — numbers normalised on entry, so SMS actually arrives
• Google reCAPTCHA — spam protection on public forms
• Google Gmail — outgoing mail through a Google account without an SMTP password

Odoo appsOnboarding ToolboxPhone Numbers ValidationGoogle reCAPTCHA integrationGoogle Gmail

Quotations and sale orders — the record every purchased session hangs off, and the left-hand end of the money chain.

• Quotations, confirmation and sale orders
• Order lines carrying the sessions or packages bought
• Delivery and invoicing status per line
• Quotation templates, for a package sold repeatedly
• Sales teams and the reporting that follows them
• The order a credit, an invoice and a payment are all traced back to

Odoo appsSales

The general ledger. Invoices, bills, payments, taxes and reconciliation — where the clinic’s books actually live.

• Customer invoices and credit notes, with issued invoices immutable
• Vendor bills — including the ones a payout run creates for professionals
• Payments, bank statements and reconciliation
• Taxes, fiscal positions and the chart of accounts
• Journals, journal entries and the audit trail behind them
• Balance sheet, profit and loss, aged receivable and aged payable

Odoo appsInvoicing

Cost and revenue attributed to something other than an account — a project, a service line, a professional.

• Analytic accounts and distributions
• Cost and revenue tracked per project or per service line
• The dimension margin reporting is computed across

The framework payment methods plug into, so adding or changing a provider is configuration rather than development.

• Payment providers configured per company
• Payment tokens, for a saved card a client reuses
• Transactions with their own state, reconciled against invoices
• The seam the gateway’s PAYMENTS flag sits behind

Three providers are switched on: a live card processor, a demo one for training, and manual methods for money that arrives outside a gateway.

• Stripe — cards, wallets and saved payment methods
• Demo — a provider that behaves like a real one, for training and rehearsal
• Custom Payment Modes — bank transfer, cash and anything reconciled by hand
• Seventeen further providers ship with Odoo and are one switch away

Odoo appsPayment Provider: StripePayment Provider: DemoPayment Provider: Custom Payment Modes

Discounts, promotions, gift cards and loyalty programmes — applied on a sale order and on the eCommerce checkout alike.

• Coupon codes and automatic promotions
• Loyalty cards and point accrual
• Gift cards, and eWallet balances
• Programme rules by product, service line or customer segment

Odoo appsCoupons & LoyaltySale LoyaltySale Loyalty - Delivery

What staff spend, and the part of it that is re-invoiced to a client rather than absorbed.

• Expense claims, approval and reimbursement
• Expenses posted straight into accounting
• Re-invoicing an expense by setting the sale order on it
• The cost side of a delivered engagement

Odoo appsExpensesSales Expense

Purchase orders and supplier management — the committed-cost side, and how vendor bills arrive.

• Requests for quotation and purchase orders
• Supplier records and pricelists
• Vendor bills matched against orders
• The order a signature can be requested on

Odoo appsPurchase

Leads and opportunities — used here for enquiries that are not yet clients, and for the consultation requests that arrive from the app.

• Leads, opportunities and a configurable pipeline
• Activities and next actions against each opportunity
• Lost reasons and win-rate reporting
• The model secure documents can be filed against for a due-diligence pack

Odoo appsCRM

Filling in what a lead did not tell you, finding leads that never made contact, and giving a sales team something to compete over.

• Lead Enrichment — company details completed automatically from an email domain
• Lead Generation — leads mined by industry, size and location
• CRM Gamification — targets, badges and leaderboards on the pipeline

Odoo appsLead EnrichmentLead GenerationCRM Gamification

A chat widget on the public site, staffed by real people, and wired into both the pipeline and the HR helpdesk.

• Live Chat — operators, channels and canned responses
• Website Live Chat — the widget on the public site and the directory
• CRM Livechat — a conversation converted into a lead without re-typing anything
• HR - Livechat — the same channel used internally for staff questions
• Transcripts kept against the visitor and, once known, against the contact

Odoo appsLive ChatWebsite Live ChatCRM LivechatHR - Livechat

The channel with the highest open rate, wired into the places a clinic actually needs it. Session reminders already use it.

• SMS gateway — the sending infrastructure and delivery status
• SMS in CRM — texting a lead from the opportunity
• Send SMS to Visitor — and the variant that works from a lead
• Recruitment - SMS — texting an applicant about an interview
• Per-person suppression, so an opt-out is honoured everywhere

Odoo appsSMS gatewaySMS in CRMSend SMS to VisitorSend SMS to Visitor with leadsRecruitment - SMS

A custom extension on leads and contacts: send a predefined WhatsApp message without leaving the record.

• Quick-send action on a lead and on a contact
• Predefined message templates
• The channel many clients in this market actually read

Odoo appsCRM Extension v2 - WhatsApp Quick Send

Periodic numbers pushed to the people who should see them, and attribution for every link the business publishes.

• KPI Digests — a scheduled summary emailed to managers
• Link Tracker — UTM-tagged short links with click statistics
• Campaign, medium and source recorded against the visitor who converted

Odoo appsKPI DigestsLink Tracker

The page builder behind the public site — the pages marketing edits without a developer.

• Drag-and-drop pages with reusable blocks
• Multi-language pages and SEO metadata
• Menus, themes and page versioning
• The public directory and professional profile pages

Odoo appsWebsite

Selling on the public site: the catalogue, the cart and the checkout a client goes through before they ever hold a credit.

• Public product catalogue and product pages
• Cart, checkout and payment on the website
• Customer accounts and order history
• The cart gates that stop an unbookable purchase

Odoo appseCommerce

The publishing side: the articles that appear in the app’s content feed and on the public site.

• Blogs, posts, tags and comments
• Multi-language posts
• The source the ranked content feed reads from

Odoo appsBlog

The three places a visitor can create a record without an account — each landing somewhere a person actually works.

• Contact Form — an enquiry that arrives as a lead, not as an email
• Online Task Submission — a website form that creates a project task
• Online Jobs — vacancies published, and applications arriving in Recruitment

Odoo appsContact FormOnline Task SubmissionOnline Jobs

Three small modules that connect the public site to the rest of the system. Nobody opens them; everything breaks without them.

• Website Mail — subscriptions and message threads on public pages
• Website Partner — a public page for a contact, which is what a professional profile is
• Website Payment — payment on the site wired to the payment framework

Odoo appsWebsite MailWebsite PartnerWebsite Payment

Employee records and contracts. In Odoo 19 a contract is a version of the employee, and that version timeline is what carries a professional’s pay terms.

• Employee records, departments and job positions
• Contract versions with a dated history, one in force at a time
• Working schedule per employee
• The record expert pay terms and payout runs are built on

Odoo appsEmployees

What each professional is qualified to do, when that qualification expires, and who reports to whom.

• Skills Management — skills, levels and progression per employee
• Skills Certification — certificates with expiry, which is what makes a credential chaseable
• HR Org Chart — reporting lines on the employee record
• HR Gamification — internal goals and badges

Odoo appsSkills ManagementSkills CertificationHR Org ChartHR Gamification

Applicants and hiring — and the reason an offer is one of the documents the e-sign stack is asked to handle.

• Job positions, applicants and a hiring pipeline
• Interview scheduling and scorecards
• Skills matched against the requirements of the role
• The applicant record a signature can be requested from

Odoo appsRecruitmentRecruitment - Skills Management

Where each person is working from on a given day — which for a clinic means knowing who is on the premises to receive a client.

• Home and office days per employee
• The same information shown on the team calendar
• Visible alongside the room calendar when planning on-site sessions

Odoo appsRemote WorkRemote Work with calendar

Projects and tasks. Used for delivery work and, in the contract vertical, for keeping the cost of winning a contract apart from the cost of delivering under it.

• Projects, tasks and stages
• Assignment, deadlines and progress
• Task-level document filing, including secure documents
• The project contract cost and margin are reported against

Odoo appsProject

A personal task list per user, separate from project work — where the small things a manager picks up during the morning routine go.

• Private to-dos with due dates
• Convertible into a project task when it turns out to be real work

Odoo appsTo-Do

Meetings and events. Every session is a calendar event underneath, which is what makes room and team calendars real rather than a rendering.

• Events with attendees, recurrence and reminders
• Availability visible across a team
• Synchronisation with external calendars
• The event a booked session is attached to

Odoo appsCalendar

Questionnaires. Used here for intake questions asked at booking and for the private feedback survey after a session.

• Questionnaires with conditional questions
• Responses stored against the person who answered
• Scoring, where a questionnaire is an assessment
• The intake questions attached to a bookable service

Odoo appsSurveys

Time recorded against a project or a task. Available and switched off on the reference deployment — it is a dependency of the contract vertical rather than of clinic work.

• Time entries against projects and tasks
• Cost per hour from the employee record
• Timesheet approval and reporting
• The hours contract billing turns into recovery and utilisation figures

A training arm: paid or free events, online courses, and a public forum — all selling through the same cart and reporting into the same books.

• Events with registration, ticketing, tracks and exhibitors
• Events sold as products through the existing checkout
• Live tracks and quizzes for online sessions
• eLearning courses, with skills earned on completion
• A public forum, and events wired into the CRM pipeline

Odoo appsEventsEvents OrganizationEvents ProductEvents SalesEvent CRMEvent CRM SaleEvent ExhibitorsLive Event TracksQuizzes on TracksSMS on EventsEvent Attendees SMS MarketingTrack Speakers SMS MarketingWebsite Events CRMeLearningSkills e-learningForum

Campaigns to lists the business already holds. The clinic sends transactional email and SMS today; this is the marketing half of the same infrastructure.

• Email Marketing — campaigns, templates, A/B testing and statistics
• SMS Marketing — the same, on the channel with the highest open rate
• Mass mailing targeted at leads, opportunities, event attendees or speakers
• Marketing Card — personalised share images for a campaign
• Newsletter subscribe buttons on the website, by email or SMS

Odoo appsEmail MarketingSMS MarketingMass mailing on attendeesMass mailing on lead / opportunitiesMass mailing on track speakersMass mailing sms on lead / opportunitiesMarketing CardNewsletter Subscribe ButtonNewsletter Subscribe SMS Template

For a clinic that also sells something physical over a counter — books, supplements, test kits — or runs a reception till.

• Inventory — stock, locations, replenishment and valuation
• Point of Sale — a till that works offline and syncs
• Point of sale discounts, and the loyalty programmes already configured

Odoo appsInventoryPoint of SalePoint of Sale - Coupons & LoyaltyPoint of Sale Discounts

The staff-administration side. Relevant once a clinic employs enough people that leave and presence stop fitting in a shared calendar.

• Time Off — requests, approval, balances, and the effect on payslips
• Attendances — check-in and check-out, with presence control
• Attendance reporting alongside timesheets
• Employee hourly wage, for costing delivered hours
• Fleet and fleet history, where vehicles are provided
• Lunch — the canteen ordering app

Odoo appsTime OffTime Off in PayslipsAttendancesTimesheets/attendances reportingEmployee Presence ControlHR Attendance HolidaysEmployee Hourly WageFleetFleet HistoryLunch

Stripe is switched on. Any of these can be added or swapped in as configuration — which is what makes entering a new market a settings change rather than a project.

• Europe — Mollie, Buckaroo, Worldline, Redsys, Adyen
• Americas — Authorize.Net, Mercado Pago, PayPal, Nuvei
• Middle East and Africa — Amazon Payment Services, Paymob, DPO, Flutterwave
• Asia — AsiaPay, Razorpay, Xendit
• Türkiye — Iyzico

Odoo appsPayment Provider: AdyenPayment Provider: Amazon Payment ServicesPayment Provider: AsiaPayPayment Provider: Authorize.NetPayment Provider: BuckarooPayment Provider: DPOPayment Provider: FlutterwavePayment Provider: IyzicoPayment Provider: Mercado PagoPayment Provider: MolliePayment Provider: NuveiPayment Provider: PaymobPayment Provider: PaypalPayment Provider: RazorpayPayment Provider: RedsysPayment Provider: WorldlinePayment Provider: Xendit

Optional external services. All are off by default, which is deliberate: each one sends something outside the estate, and that should be a decision rather than a default.

• Google Calendar — two-way sync for staff diaries
• Google Maps and places autocompletion on the website
• Google Address Autocomplete on contact forms
• Google Users — sign-in with a Google workspace account
• Cloud Storage on Azure or Google, for attachments at scale

Odoo appsGoogle CalendarGoogle MapsGoogle places autocompletionGoogle Address AutocompleteGoogle UsersCloud StorageCloud Storage AzureCloud Storage Google

Odds and ends that each solve one narrow problem. Listed for completeness rather than because a clinic needs them on day one.

• Mail plugins for Outlook and Gmail, on CRM and on Project
• Mail Group — a mailing-list style discussion, with a website archive
• Data Recycle — finds duplicate and stale records
• Website profile — a public page for a portal user
• Recruitment interview forms, and sales expense margin reporting
• A CRM telephony integration (Issabel)

Odoo appsMail PluginCRM Mail PluginProject Mail PluginMail GroupWebsite Mail GroupData RecycleWebsite profileHr Recruitment Interview FormsSales Expense MarginCRM Issabel Integration

The agreement, its parties, its structured terms with provenance, its versions, and a workflow of configurable stages mapped to five fixed phases.

• Agreements with parties, structured terms and term provenance
• Versions, so "what did it say in March?" stays answerable
• Configurable stages mapped to five fixed phases
• No industry vocabulary and no dependency on e-signature, encrypted storage or projects
• Industries arrive as packs of configuration rather than as forks of the code

Built so that review is directed at what changed and what deviates, and never at unchanged boilerplate — which is where contract systems are usually abandoned.

• A clause library linked to structured terms, so accepting a fallback sets the term it carries
• Playbooks, rounds, issues and recorded deviations
• Meetings as negotiation rounds in their own right, keeping the reasoning and the positions
• A meeting outcome creates proposed changes and never changes the contract by itself
• A log tying every stage from request to execution together, with every gap visible

Approval decided on more than one axis. Treating it as seniority alone is the common design error: a standard NDA at any value needs nobody senior.

• Approval on value, deviation, contract type and risk
• Deviation as an axis in its own right rather than a modifier on value
• Approval by a delegate always recorded as such — "on behalf of" is a different fact
• Works on Odoo Community, where the Approvals app is not available

Records what an amendment changed, not merely that it exists.

• Executing an amendment closes the term rows it varies and opens new ones at the effective date
• Anything derived from a changed term recalculates, and the movement is shown before execution
• Conflicting amendments detected at execution
• A lapsed waiver revives the term in force at lapse, not the original

Signature is the beginning of the obligation, not the end of a workflow. This carries what happens afterwards.

• Obligations in both directions, with evidence where evidence is required
• Derived dates calculated from terms rather than typed, and moved when their driver terms move
• An escalation ladder that does not rely on reminding the person who has already not acted
• The renewal decision presented with the obligations the counterparty has missed

Two costs, kept apart: what a contract cost to win, and what it costs to deliver. Combining them produces a number that answers neither question.

• Negotiation effort recorded as overhead, whether or not the contract signs
• Delivery cost recovered against the contract value
• Contracts linked to projects many-to-many with a role, because one project field breaks on the first framework agreement
• A signed supplier contract is committed cost from execution, not from its first invoice

What an hour is worth, what the fee allows, and the four figures that need both.

• Charge rates, a billable flag and a billed state on recorded time
• Fee bases stated on the contract
• Recovery — billed against the value of time recorded
• Utilisation — billable hours against hours available, from the person’s own working calendar
• Lock-up — unbilled work plus uncollected bills, and how many days of billing that is
• A capped-fee warning driven by projected cost, because one that fires at the cap fires too late

The fourth exchange channel: the counterparty reads the current version here, comments, and uploads their markup as an inbound round.

• The counterparty opens the current version, comments on it and returns their markup
• Markup arrives as an inbound round with the file attached, not as an email somebody must remember to file
• Nothing internal is visible — not positions, deviations, approvals, the playbook or internal notes
• Optional, because a design that assumes the counterparty will use our portal fails on the first large customer

How a contract uses the signature service. Completion is the event that starts everything else.

• Approvals must be complete before a version can be sent
• The signatory’s authority to bind checked against their credential
• The version locked when it goes out, so every later claim about what was signed is provable
• On completion the version is executed, the contract moves, terms activate and derived dates follow
• Uninstalling leaves a working system — paper signatures are recorded with a method and look complete

Encrypting every contract makes the system unusable; encrypting none makes it unsafe. So confidentiality is a level on the agreement.

• Only agreements marked secure route their documents into the secure document service
• Per-version encryption under a key held outside the database
• Default-deny access, and every read logged before content is returned
• Disposal by destroying the key
• Says at the point of change that upgrading to secure does not undo having stored something unencrypted

Flag lists that should be empty, and the management views worth arguing over.

• A flag list holds only what is out of line — an empty list is the good outcome
• A flag whose model is not installed reports as not applicable rather than failing
• Uncapped liability shown as a list, never as a number added into a total
• Cycle time split by side, because days the counterparty held the draft are not the contract team’s performance
• Depends only on the core, and removing it leaves a working system

Three readers, one arithmetic. The same numbers computed once and rendered three ways, rather than re-derived per screen where they would drift apart.

• A single deadline view: derived contract dates, obligations both ways, actions agreed at meetings and delivery deadlines
• Project control: revenue, labour, committed cost, margin and estimate variance, as a stored view so it can be grouped
• A client-facing view of where the work has got to and what is owed
• A lawyer-facing view of what is on them this week and whether they are inside the estimate

Two rules, and only two — the ones that compare records and therefore cannot be expressed as configuration.

• A sublicence’s territory must sit inside its parent’s
• Two exclusive licences must not overlap
• Kept separate from the IP pack, so a business can install the contract types without the checks
• Its size is a deliberate measure of how well the base’s extension points are working

Conflict checking at contract intake, the same as matter opening. It gates the stage transition; it does not warn.

• A counterparty checked against existing clients, opposing parties on live matters, and known affiliates
• Gates the stage transition rather than raising a warning that can be dismissed
• The check itself immutable once recorded — who ran it, over what scope, and what they found

The starting pack. Install the core and this, and a business can run contracts on day one without configuring anything.

• NDAs, master agreements, statements of work, services, consultancy, supply and purchase
• The terms each type carries and the workflow it moves through
• Gates that stop a contract reaching signature half-formed
• No Python — and specialised packs depend on this one rather than redeclaring what everybody needs

Employment, contractor engagement, consultancy and settlement.

• Agreement types, term types, clause library and playbook for employment contracting
• Obligation templates for notice, probation and post-termination terms
• Settlements default to secure — every word matters, and a regulator later asks about them
• Data only, and no rules module

Law firms — contracts for clients and with them — and in-house legal departments. The same system serves both jobs with sharply different defaults.

• Engagement letters, retainers and counsel instructions
• A clause library with the regulated wording marked mandatory
• A firm’s engagement letter defaults to confidential and itemised
• Conditional fee agreements carry wording that cannot be removed
• Conflict checking lives in contract_legal_rules, because it compares parties across matters

Licensors, patent and trademark holders, technology transfer offices, universities and brand owners.

• Licences, assignments and options as agreement types, with licence term types
• Clause library, playbook and obligation templates
• No asset register, deliberately — a patent’s prosecution history belongs to the portfolio system that already holds it
• The two rules a pack cannot express live in the optional contract_ip_rules

Leases, agreements for lease, licences to occupy, sales, easements and the deeds that hang off a lease.

• Break dates as date-driving terms, because a break right expires in silence
• The notice window as an obligation derived from the break date, and both escalate
• Rent review, service charge and reinstatement terms
• Data only, and no rules module

Debt documents: facility agreements, guarantees, security, intercreditor and subordination deeds.

• Financial covenants as structured terms, with derived test dates
• The compliance certificate as an obligation with evidence required
• "Which facilities are tested this quarter, and on what numbers?" becomes a question with an answer
• It documents debt; it does not account for it — balances and accruals stay in accounting
• Data only, and no rules module

Main contracts, subcontracts, professional appointments, collateral warranties and the instruments around them.

• Built around the chain: a main contract promises a date only the subcontracts can deliver
• Back-to-back terms held as structured terms so they can be compared down the chain
• Liability that the subcontracts and the professional indemnity cover have to carry
• Data only, and no rules module

Data processing agreements, business associate agreements and sub-processor terms.

• DPA, BAA and sub-processor agreement types with the terms they carry
• The breach-notification window as its own term, because it is measured in hours
• Audit response and sub-processor notice as derived dates
• Data only, and no rules module