115 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

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

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

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 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

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 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

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

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