Thrivelab Zoho CRM — generated 2026-05-19 from a fresh extraction of 210 modules and 937 workflow rules, classified by recent (last-30-day) Deluge function activity.
This document is organized into 10 business domains. Within each domain, modules are split into two tiers:
The activity badge after each module heading shows active functions / total .deluge files in last 30 days, plus active workflow rule count where significant.
Companion materials: MODULES_INDEX.md (one-row directory), graph_domains.html (10-domain rollup), domain_graphs/ (per-domain mini-graphs), graph.html (full interactive graph).
This domain covers the top of Thrivelab's patient funnel: how prospective patients are captured (web forms, ads, chat, referral partners, radio), tracked across the assessment-and-booking journey, contacted by the sales/Direct Patient Care (DPC) team, and ultimately converted into Contacts. It also contains the satellite systems that feed acquisition — ambassador (affiliate) management, investor outreach, and post-visit feedback/NPS surveys that close the loop back into marketing.
Purpose. Leads is the single inbox for every prospective patient who has not yet converted into a paying Contact. It captures the full intake snapshot — hormone/wellness symptom assessments, demographics, ad attribution, and booking metadata — for the four product lines Thrivelab markets (hormone therapy, weight loss, stem cell, peptides/longevity). Every web form, Facebook lead ad, Zoho Booking, chat, and radio call-in lands here first.
Connections.
- Out: Converted_Contact → Contacts, Converted_Account → Accounts, Converted_Deal → Deals (on conversion); Referred_By → Contacts (patient-to-patient referrals); Partner → Ambassador_Management; Payor → Payors.
- In (related lists): Lead_conversion records, Self_Assesments, Weightloss_Forms, Stem_Cell_Assessment, OTP_Verification, AI_assistant_chats, Visitor_Tracking, Agent_Responses, Funnel_Tracking, Affiliate_Events, Longevity_Installments, Calls, Events, Tasks, SMS_Backup, Campaigns. Visits from Zoho SalesIQ and Zoho Desk/Survey tickets attach here too.
Automation. Roughly 100 active workflow rules — the most heavily automated module in the system — covering SMS/email outreach, lead routing & assignment, deduplication & data quality, status transitions, integrations.
Business role. If Leads disappeared the entire patient acquisition engine stops — paid-ad attribution, the self-assessment-to-free-consult pipeline, DPC round-robin assignment, the men's/women's nurture SMS drips, after-hours routing, and the stem-cell and TN-abandon campaigns all live on this module.
Purpose. The activity log of every phone touch between Thrivelab and a Lead/Contact — outbound sales calls from DPC reps, inbound patient calls, missed calls, voicemails, and CTI/Kixie telephony events. It is both the "what happened in the sales conversation" record and the trigger surface for downstream SMS/task automations.
Connections. Who_Id → Contacts, What_Id → polymorphic (Leads, Deals, Cases, etc. via Zoho's "se_module"). Surfaced as Open Calls / Closed Calls on essentially every entity in the CRM (Leads, Contacts, Deals, Ambassador_Management, Investors, etc.).
Automation. 10 active rules:
- On create: Missed Call alert, Count_Response_Time (measures first-call latency after lead creation), Update count of calls.
- On missed_call: Missed Call alert-1, Missed Call Task.
- On scheduled_call_createedit: Count_Response_Time-1.
- On outgoing_call_createedit: Send SMS on VMDrop Call Result, Update Last Call Date.
- On outgoing_call_field_update: Provider Escalation - Auto-Close Tasks, Provider Escalation - Send SMS if voice message.
Business role. If Calls disappeared, the entire sales-and-provider phone operation goes dark — DPC response-time KPIs, voicemail-drop SMS follow-ups, missed-call task creation, and provider escalation flows all depend on this module's events.
Purpose. A coarser, higher-level conversion-funnel ledger that groups events by program line (Conversion_Funnel: ITH, TN, Pep, Nut, VPC, WL, Trainer). Where Visitor_Tracking is page-level telemetry, Funnel_Tracking records milestone events (Creation, Conversion, Assessment Completed, Meeting Booked) per Lead/Contact per program.
Connections. Lead → Leads, Contact → Contacts. Surfaced as the "Funnel Tracking Events" related list on Leads.
Automation.
- Conversion Type NoteBusiness role. Provides per-program cohort analytics (e.g. "how many ITH leads completed assessment last week vs converted"). If gone, the team would lose the cross-program funnel rollup that distinguishes weight-loss conversions from stem-cell or peptide conversions.
Affiliate Events · no Deluge code
The per-event log of affiliate-network conversions, populated from Everflow (Type picklist is currently just "Everflow"). Each row is one tracked event — a click attribution, signup, or purchase — tying an Everflow Transaction_ID and Offer_ID to the Lead/Contact who converted and the Ambassador who gets credit.
Lead → Leads, Contact → Contacts, Ambassador → Ambassador_Management.
If this disappeared: This is the joining table that turns "an ambassador has a partner ID" into "this specific patient lead was driven by that ambassador on this date for this offer." Without it, rev-share calculations have no source of truth and the Everflow integration has nowhere to write.
Agent Responses · no Deluge code
Holds AI-drafted (or agent-drafted) message replies — typically SMS or email responses to a Lead/Contact — pending human review before send. Each record carries the proposed Content, the Channel, optional Comments, quality Flags (Inappropriate, Off-topic, Not Helpful, Inaccurate, Other), and an Approve (Yes/No) decision.
Lead → Leads, Contact → Contacts.
If this disappeared: The human-in-the-loop quality gate for AI-generated patient messaging. Without it, AI-drafted replies would either need to be sent without review or scored in a separate tool — and there would be no audit trail of why a draft was rejected.
Ambassador Management · no Deluge code
The directory of Thrivelab's referral/affiliate partners — influencers, content creators, and B2B partners who refer patients in exchange for revenue share. Each row is one ambassador's profile: contact info, Instagram handle, Everflow partner ID (the affiliate-tracking network), revenue percentage, and contract status.
Contact → Contacts.
If this disappeared: Without this module the affiliate program collapses — Thrivelab could not tie an Everflow click/conversion back to a partner, generate the per-partner promotional links, or compute revenue share owed.
Ambassador Payment Detail · no Deluge code
Stores the bank/ACH payout instructions for an ambassador — the "where to send the money" record, kept separate from the ambassador's profile for privacy/access-control reasons.
Contact → Contacts.
If this disappeared: The vault for ambassador banking info. If lost, finance could not actually pay any ambassador — Ambassador_Payments rows would have nothing to point at.
Ambassador Payments · no Deluge code
The ledger of actual disbursements to ambassadors. One row per payout: amount, date, and a reference to the Ambassador_Payment_Detail (bank info) it was paid against.
Ambassador_Payment_Details → Ambassador_Payment_Detail.
If this disappeared: The audit trail for ambassador-program disbursements. Without it, finance has no record of which partners were paid how much and when.
Campaigns · no Deluge code
The standard Zoho marketing-campaign object Thrivelab uses to label every paid/organic outreach push (Zoho Campaigns email blasts, Zoho Survey runs, partner programs, trade shows, radio). Leads and Contacts attach to a Campaign so ROI (Expected Revenue vs Actual Cost, Num sent vs Expected Response) can be measured per push.
Self-referential Parent_Campaign → Campaigns (parent/child).
If this disappeared: The system of record for marketing ROI rollups. Without it, leads would still carry ad-attribution fields, but there would be no place to aggregate spend vs revenue per push and no way to drive Zoho Campaigns/Surveys.
Investors · no Deluge code
A capital-raise CRM module (not patient-acquisition in the clinical sense) tracking pitched investors for Thrivelab's fundraising — angels, family offices, healthcare VCs, and the WeFunder crowdfunding pool. It lives in the same CRM tenant so the corporate-dev team can use cadences/email tooling against investor contacts.
None — no lookups in or out.
If this disappeared: The fundraising team's pipeline. If removed, the WeFunder reconciliation, pitchbook outreach tracking, and per-investor commit ledger lose their home. Distinct from patient acquisition, but bundled here because it shares the same Zoho tenant and cadence tooling.
Lead Conversion · no Deluge code
A staging/handoff record created during the Lead-to-Contact transition. It captures the choices the rep (or "Sales Closer" integration) made at conversion time — which services to attach, coupon used, payment timing (pay now vs pay later), shipping address, and the generated payment/booking links — so the downstream Contact and Deal records can be populated consistently.
Sits between Leads and Contacts: Lead → Leads, Contact → Contacts.
If this disappeared: If this module went away, the conversion event would lose its audit trail: there would be no record of which payment link was issued, which coupon applied, or which services were attached when a Lead became a Contact — and the Sales Closer integration would have nowhere to write back.
Lead SMS Templates · no Deluge code
A tiny lookup table of reusable SMS message bodies the team can drop into outbound texts to Leads. It is effectively a key-value store of canned messages (autonumber name + Message textarea) rather than a transactional module.
None.
If this disappeared: A convenience library — if it disappeared, reps would need to keep canned SMS copy somewhere else (a shared doc, Kixie templates), but no automated flow depends on it.
Mobile App Feedback · no Deluge code
Captures structured feedback from patients who used the Thrivelab mobile app — bug reports, UI ratings, NPS-style "how likely to recommend," and questions about whether specific features (health tracking, navigation) work. One record per submission.
Contact → Contacts.
If this disappeared: Product/engineering's feedback queue for the mobile app, plus a small loyalty-program lever. If gone, mobile bug reports and app-NPS would need an alternative intake — and patients would lose the 100-point credit incentive.
Patient Feedback · no Deluge code
A deliberately thin free-text feedback inbox — one Contact, one Patient_Feedback textarea. This is the catch-all "tell us what you think" box, distinct from the structured NP Surveys and Mobile App Feedback flows.
Contact → Contacts.
If this disappeared: A low-friction patient-voice intake. If removed, unstructured patient comments would have to live as Contact notes or external survey tools; nothing critical breaks, but qualitative voice-of-customer data loses its home.
Survey (NP Surveys)
Labeled "NP Surveys" in the layout — the post-visit NPS-style survey patients fill out after seeing a Nurse Practitioner. Captures provider rating and Net Promoter Score for the specific visit, plus optional free-text suggestions and a Trustpilot prompt flag.
Contact_Name → Contacts; Nurse_Practitioner → Users.
If this disappeared: The provider-quality scorecard and Trustpilot-review pump. Without it, leadership loses per-NP NPS rollups and the practice loses its main inbound channel for public reviews.
Surveys · no Deluge code
A separate, sparse survey module attached to chat/SHM (Secure Health Messaging) conversations rather than to NP visits. Captures simple satisfaction signals (how easy, how comfortable, free-text feedback) after a Chat-channel interaction closes.
SHM → Chats.
If this disappeared: The chat-channel NPS analog. Lets the team measure satisfaction with the SHM/Chats experience separately from clinical NP visits. If removed, post-chat satisfaction would be invisible — the Chats automation that creates these rows would have nowhere to write.
Visitor Tracking · no Deluge code
Captures funnel telemetry events emitted by the Thrivelab web property as a prospect moves through the assessment-and-booking flow. Each row is one event (e.g. start_assessment, completed_assessment, start_fc_booking, try_appointment_payment) tied back to the Lead or Contact who triggered it.
Lead → Leads, Contacts → Contacts, Service → Bookings_Services.
If this disappeared: This is the raw event log marketing and product use to debug funnel drop-off ("did they try to pay and fail?", "did they complete the assessment but never book?"). Without it the team would be flying blind between "Lead created" and "Free Consult booked."
This domain is the clinical and identity core of Thrivelab's CRM — the converted patient (Contacts) plus every structured record that documents who they are, what they consent to, what's wrong with them, what they're allergic to, what device readings they generate, and how they prove identity. It spans the four product lines (peptides, weight loss, stem cell, hormone/longevity) and is the data layer every other domain (orders, prescriptions, lab orders, encounters, fulfillment) joins back to. With the exception of Accounts — which Zoho ships by default but Thrivelab barely uses in this B2C model — every module in this section hangs directly off Contacts.
Purpose. Contacts is the universal patient record and the single most central module in the entire CRM. Every converted patient — from intake through prescription refills through offboarding — lives here, and 130+ other modules link back through a lookup field. With 366 fields it acts as both the demographic master record and a rolling status/scoring snapshot: stage, owner, NP, DPC, insurance posture, SMS-loop state, lab/plan readiness, and per-program completion dates all live on the contact row itself.
Connections. Out: Vendor_Name → Vendors, Thrive_Together_Referral → Contacts (patient-to-patient referral), Payor → Payors, Coupon → Coupons, Partner → Ambassador_Management. In (related lists, abbreviated — there are ~165): Intake_Form, Stem_Cell_Intake_form, Mindlab_Intake_Form, Patient_Allergies, Medical_History, Medical_Conditions, Mental_Wellbeing, Surgical_Procedure, Health_Data, Health_Parameters, Government_IDs, Vendor_IDs, Mobile_App_Devices, OTP_Verification, Consent, Insurance, Claim_Information, Sales_Orders (Patient Plans), Supplement_Order, External_RXs, Treat_Events (Rx history), Lab_Orders, Lab_Req_info, Encounters, Self_Assesments, Weightloss_Forms, Stem_Cell_Assessment, Longevity_Installments, Care_Team, Action_Items, Chats, SMS_Backup, Emails, Calls, Events, Tasks, Wallet, Shopping_Cart, Fulfillment_Requests, Shipment_Requests, Replacements, Early_Refill_Requests, Refund_Discount_Requests, Approvals_Module, Access_Log, Funnel_Tracking, Campaigns, AI_assistant_chats, Mobile_App_Feedback, Patient_Feedback. In short: virtually every clinical, operational and financial module in the system attaches to a Contact.
Automation. Roughly 90 active rules — the most heavily automated module after Leads — covering clinical workflow, SMS/email outreach, lead routing & assignment, task creation, status transitions.
Business role. If Contacts disappeared, the practice ceases to function — there is no patient record, no care-team assignment, no consent/intake status, no clinical scoring, no insurance posture, no link between a patient and their orders, prescriptions, labs, encounters, or payments. It is THE patient master.
Purpose. The primary structured medical-intake questionnaire — Thrivelab's HIPAA-style new-patient profile. With 160 fields it captures the full picture: chronic conditions, family history, current medications, organ-system review (cardiovascular, endocrine, neurological, psychiatric, etc. as multi-select picklists), women's/men's preventive-screening dates, lifestyle (alcohol/smoking/exercise/diet), emergency contacts, preferred pharmacy, primary-care provider, specialist, telehealth-consent acknowledgements, and which Profile Sections the patient has completed in the portal.
Connections. Out: Contact_Patient → Contacts, Patien_Plan → Sales_Orders. In (related lists pointing back to Intake_Form via the Intake field): Patient_Allergies, Medical_History, Mental_Wellbeing, Surgical_Procedure (Medical Procedures), Government_IDs, Patient_Medications (External Medications), Weightloss_Forms (Nutritional Choices), Fitnes_and_Training, Insurance, Insurance_Requests. The intake is the hub that fans out the patient's structured-data submodules.
Automation.
- Push Data for intake form on server— pushes the intake payload to the external server
- Sync_Patient_Plan- Action Items and Insurance SMS- check_insurance_information- History of Cancer Task - Intake— flags oncology history for review
- create_plan_for_vpc— spins up the VPC plan when relevant
- Add Intake Form Notes to Contacts— pushes intake notes back onto the Contact
- MP - Mark Medical Profile as Completed- MP - Sync Insurance to Medical Profile- Trigger TN Email and SMSBusiness role. Without Intake_Form, the practice has no structured new-patient profile — NPs would walk into the initial telehealth visit blind, the medical profile completion logic breaks, the cancer-history triage stops firing, and the downstream allergies/medications/surgical-history submodules lose their parent.
Purpose. The intake landing record for the Stem Cell / longevity program. Like the Mindlab intake it is a stub (16 fields) — its job is to record that a stem-cell candidate submitted an intake and attach it to the right patient; the substantive screening lives in Stem_Cell_Assessment and on the patient's Longevity fields.
Connections. Out: Contact → Contacts. In: Patient_Medications as "Stem Cell Intake" — i.e. medications captured in the stem-cell intake stream attach back here.
Automation.
- Add Contact to Stem Cell Intake Form— links the intake to the contact on creation
Business role. If this disappeared, Stem Cell program candidates would have no intake-submission record on file; the Stem_Cell_Assessment + Longevity_Installments funnel would still work, but the front-door acknowledgement and the patient-medications attachment to the stem-cell stream would break.
Purpose. A per-patient log of historical medical events tied to either an Intake form or a Patient Plan. The schema is intentionally thin (18 fields) — it acts as a header row whose detail lives in related Notes and Attachments, and as a parent for the cancer-history workflow.
Connections. Out: Contact → Contacts, Intake → Intake_Form, patient_plan → Sales_Orders. In: Notes/Attachments only.
Automation.
- History of Cancer - Medical Profile— flags oncology history when a Medical_History record is created
Business role. If this went away, the patient's longitudinal medical history (separate from the point-in-time intake snapshot) would have nowhere to live, and the cancer-history-on-medical-profile alert would stop firing.
Accounts · no Deluge code
Zoho's default B2B "company" object. Thrivelab is a direct-to-consumer healthcare practice, so individual patients are stored in Contacts, not Accounts. The module exists with all the stock Zoho fields and is wired to Deals, Quotes, Sales_Orders, Invoices, Cases and ZohoSign, but Thrivelab does not use it as part of the patient-profile flow.
Out: Parent_Account → Accounts (self-reference).
If this disappeared: If Accounts disappeared, almost nothing in Thrivelab's day-to-day operation would break — it is effectively shelfware that Zoho requires you to keep around. The only minor loss is the optional B2B audit trail for partner clinics or corporate clients if/when those exist.
Additional_Questions · no Deluge code
Not a per-patient submission — this is a configuration/library table of extra screening questions that can be attached to specific Bookings services (e.g. "before this appointment type, ask the patient X"). Each record defines one question, its options, type (Single/Multi/Text), whether it is required, and which Bookings service it belongs to.
Out: Service → Bookings_Services.
If this disappeared: If this disappeared, booking flows would lose their service-specific pre-appointment questionnaires — patients could book without answering the extra screening Thrivelab tied to that service type.
Consent · 1 function(s), 0 active
A very thin module (13 fields, no custom fields) that records a consent-form submission event. The substantive consent document lives as an attachment / ZohoSign artefact; this record is the CRM index entry that says "consent N was captured for this email." The contact's Consent_Signed_date and Accepted_terms boolean carry the actual status — this module is the receipt.
No lookup fields and no Patient/Contact related list defined on this module.
If this disappeared: If this disappeared, Thrivelab would lose its CRM-side audit log of consent submissions — the practice would have to rely solely on ZohoSign / Woosender data and the Consent_Signed_date field on the Contact, weakening the HIPAA paper trail.
Government_IDs · no Deluge code
Per-patient identity documents — driver's license or military ID — captured for legal and prescription/DEA compliance (Thrivelab prescribes controlled substances in some programs, and DL is required for several states). Each record holds the ID number, type, and the URLs of the uploaded front/back images.
Out: Contact → Contacts, Intake → Intake_Form.
If this disappeared: Without this, the practice has no structured record of patient government IDs — the DEA / controlled-substance checks, the state-licensure verification, and the Needs_DL SMS reminder loop on Contacts all lose the artefact they reference.
Health_Data · no Deluge code
A session-level container record for health measurements collected from the patient's mobile app / wearable. Each Health_Data row represents one collection window (start/end timestamp) on one device, and groups the individual measurements (Health_Parameters) that were captured during that window. This is the entity / envelope record.
Out: Contact → Contacts, Device_data → Mobile_App_Devices.
If this disappeared: Without Health_Data, individual Health_Parameter measurements have no envelope — there is no way to say "these 47 readings came from this patient's iPhone HealthKit between 8am and 10am yesterday," breaking the wearable/mobile-app sync pipeline.
Health_Parameters · no Deluge code
The individual measurement rows that live under a Health_Data session — one row per data point. This is the what was measured table: a typed measurement (heart rate, steps, weight, blood pressure, etc.), its value, its unit, the time window it covers, and arbitrary metadata.
Out: Health_Data → Health_Data (parent envelope).
If this disappeared: This is the raw measurement table — losing it means losing all device-streamed vitals from the patient mobile app, leaving the practice with only what's entered manually in Vital_Signs / Encounters.
Medical_Conditions · no Deluge code
A structured list of the patient's active chronic conditions — one row per condition, with onset, current management status, and whether it is being managed by medication or another specialist. This is the queryable, normalised version of the free-text Chronic_Conditions field on Intake_Form, used by clinicians and by downstream prescription-safety logic.
Out: Contact → Contacts, Plan → Sales_Orders.
If this disappeared: Without this, NPs and the AI audit/AI-output pipelines lose the clean, per-condition record they need to check contraindications and to render the patient's problem list — clinical safety regresses to scanning free-text intake fields.
Mental_Wellbeing · no Deluge code
A per-patient key-value store for mental-wellbeing self-assessment answers (e.g. stress score, sleep quality, anxiety rating). Each row is a single named metric and its value, captured at intake time — a normalised version of the Mental Wellbeing & Stress Levels section of the Intake_Form portal.
Out: Contact → Contacts, Intake → Intake_Form.
If this disappeared: Drives the Mindlab/life-coaching program's baseline measurements — losing it would mean the practice can no longer track changes in patient-reported mental-wellbeing scores over time, and Mindlab providers lose the baseline they coach against.
Mindlab_Intake_Form · no Deluge code
A lightweight intake for the Mindlab / life-coaching program (Thrivelab's mental-wellness arm). Unlike the main medical intake, this is a stub record (only 15 fields) that exists primarily to record that a Mindlab intake submission happened, link it to the patient, and trigger downstream actions; the actual questionnaire content lives elsewhere (in Notes/Attachments and on the Contact's Mindlab fields).
Out: Contact → Contacts.
If this disappeared: If this module disappeared, Mindlab intake submissions would lose their CRM landing record — the life-coaching program would lose its acknowledgement audit trail and the corresponding contact-level Mindlab_Intake_Completed_Date automation would not fire.
Mobile_App_Devices · no Deluge code
A registry of the patient's mobile-app installations — one row per device. It stores everything the practice needs to push notifications to that device, verify its identity, and tie health-data uploads back to it. This is the device-identity backbone of the Thrivelab patient mobile app.
Out: Contact → Contacts.
If this disappeared: If this disappeared, the patient mobile app loses its server-side device registry — push notifications cannot be addressed, signed requests cannot be verified, and the Health_Data sync loses the device foreign key that says where each measurement session came from.
OTP_Verification · no Deluge code
Stores one-time-password verification challenges issued to leads and patients during phone-verification flows (login, lead self-verification, sensitive-action confirmation). Each row is one issued OTP with its code, expiry, verified flag, and the phone it was sent to.
Out: Lead → Leads, Contact → Contacts.
If this disappeared: Without OTP_Verification, the practice's phone-verification flow (used by the Leads self-assessment, mobile app login, and high-risk actions) has nowhere to record issued codes, breaking SMS-based 2FA / lead phone validation entirely.
Patient_Allergies · no Deluge code
Per-patient allergy list — one row per allergen, with severity and reaction notes. Critical safety data: every prescription/lab/refill flow checks this list, and the intake portal explicitly drives patients to populate it.
Out: Patient → Contacts, Patient_Plan → Sales_Orders, Intake → Intake_Form.
If this disappeared: This is the canonical "allergy list" for the practice — if it disappeared, NPs would have to read free-text intake fields to know what a patient is allergic to, and the audit/prescription-safety logic that joins on Patient_Allergies would silently degrade.
Vendor_IDs · no Deluge code
A mapping table that ties a patient (Contact) to their corresponding customer IDs in each external vendor system Thrivelab integrates with — Zoho Books (multiple ledgers), Authorize.Net (multiple profiles), Treat/DosePot (e-prescribing), Zoho Desk, and the Kept mobile app. One row per patient holding all the foreign keys.
Out: Contact → Contacts.
If this disappeared: If Vendor_IDs disappeared, every cross-system integration that needs to translate "Thrivelab Contact 123" into the corresponding Books customer, Authorize.Net profile, DosePot patient, or Kept user breaks — payments, e-prescribing, and accounting all lose their join key.
This guide documents the Clinical Care domain of Thrivelab's Zoho CRM — the modules that anchor every patient interaction from the moment a visit is scheduled to the moment the SOAP note is locked, claims are filed, and follow-up care is dispatched. Encounters sit at the heart: they hold SOAP narratives, CPT/ICD-10 coding, the provider/PCA assignment, vitals references, and the eligibility/billing context for the practice's telehealth, weight-loss, BHRT, stem-cell, and regenerative-medicine services. Surrounding Encounters is a constellation of supporting modules: service catalog (Bookings_Services), provider-service-state assignment matrices (Service_Provider, State_Provider, Service_Locations), the staff registry (Books_Agents), care-team rostering (Care_Team), structured clinical intake (Weightloss_Forms, Vital_Signs, Home_Visit_Info), AI-assisted documentation review (SOAP_Writing_Suggestions), service enrollment/billing state (Enrolled_Services, Verified_Services, Services_x_Contacts), and operational approval queues (Approvals, Approvals_Module). Together they implement the clinic's compliance, scheduling, documentation, and billing chain.
Purpose. The clinical anchor of the CRM — a single Encounter record is the structured representation of one provider-patient visit (telehealth, in-clinic, home visit, follow-up, nurse consult, etc.). It captures SOAP narrative, CPT/ICD-10 coding, meeting metadata, billing posture, and locking/audit state.
Connections. IN: Care_Team rows reference an Encounter; SOAP_Writing_Suggestions, Clinical_Assistant_Recs, Supplements_x_Encounters, Encounters_X_ICD_10_Codes, Claim_Information, Claims, Imaging_Labs, External_Referrals, VPC_Lab_Order, and Vaccine_Order all attach to Encounters as related lists. OUT: lookups to Contacts (Patient), Books_Agents (Provider), Sales_Orders (Plan), Clinic_Addresses, Chats, and Longevity_Installments (Stem_Cell_Plan).
Automation. ~28 active workflow rules — grouped by trigger:
- field_update (the dominant trigger): Meeting_Admin_time, sync_meeting_status, Meeting Duration, Sync_SOAP_Notes, sync_plan_medications, Sync meeting time, Calculate Meeting_Admin Time, meeting_plus_admin_time, Create_Doc_When_Addendum_Is_Added, sync_icd_to_pp, Save_ICD10Codes_Before_Transition, Create and send emails to Referrals, Schedule Task for Provider - Plan Modification, update virtual care included, check CPT code, Check_for_ICDCodes_Encounter_Locked, Sync Chronic Conditions based on ICD10 codes, External Pharmacy Meds, Update Deposit Payment Date - Longevity Installments, Data Cleanup Workflow, Jot Form Reminder Time, create_claim_record, add_note_when_encounter_is_locked.
- create: Mindlab/Nutrition Workbook, Add Encounter Notes to Contacts.
- date_or_datetime: HR Encounter Check Task (HR reviews time-documentation discrepancies), Encounter not locked task.
Business role. Without Encounters the practice has no legal clinical record, no claim source, no SOAP audit trail, no CPT/ICD coding feeding insurance, and no trigger surface for medication-sync, lab-ordering, referral-creation, addendum-locking, or HR documentation review — every downstream billing and care-coordination process unravels.
Purpose. The active subscription / service-enrollment ledger per patient: which services they are currently enrolled in (TransformNation Insurance/Cash, Thrively Insurance/Cash, Peptides, BHRT, NTC, VC, Sam Sweeney Subscription), the recurring-invoice and standalone-invoice cadence, start/next/last invoice dates, discount lines, add-ons (Fitness/Nutrition/Health), and trainer assignment. It is the recurring-revenue + subscription state of each patient.
Connections. OUT: Contacts, Trainers. IN: Service_Status_History, Suscription_Payments (Payments), Payment_Methods (Connected_Record_Child).
Automation. 8 active rules — grouped by trigger:
- create: Enrolled Services Actions. Create RI-Action Item-Comms (the big one — creates RI 2 min after creation, fires Book-Appointment reminders at 1h/1d/3d for TN patients, creates Action Item / note when no services available).
- field_update: Sync RI to CRM.
- date_or_datetime: Update RI - Add Fitness Addon, Update RI - Add Nutrition Addon, Update RI - Add Health Addon, Update RI - Remove Fitness Addon, Update RI - Remove Nutrition Addon, Update RI - Remove Health Addon.
Business role. If it disappears, the practice loses its source of truth for what each patient is subscribed to and how Zoho Books recurring invoices are kept in sync — billing cadence, add-on lifecycle, and the appointment-booking reminder cascade for new TransformNation enrollees all break.
Purpose. Junction (linking) module connecting Contacts to Service_Provider rows so a single patient can have many provider-service associations (each Related_Services is a Service_Provider, plus a Main_Service lookup to Bookings_Services for service-level metadata). It is the row-level "this patient may book this provider-service" mapping with payment-type and portal-visibility flags.
Connections. OUT: Contacts, Service_Provider, Bookings_Services. This is the "real" services-to-contacts junction the workflows operate on.
Automation. 6 active rules — grouped by trigger:
- create: Generate Link, Service Visibility, Change Provider Assigned SxC, Create Care Team.
- field_update: Service Visibility TH/PR LCI/LCF NCI/NCF, Update Care Team Provider.
Business role. If it disappears, the patient-facing portal cannot generate per-patient booking links, and Care_Team rows stop being created when a service is granted — schedulability and care-team rostering both break.
Purpose. The integration log between the CRM and the Treat (DigitalRx/Treat platform) e-prescribing system. Each Treat_Event is a payload-bearing event capturing a prescription written or fulfilled during an Encounter — drug, sig, quantity, pharmacy, refills, prescriber — which then drives External_RXs and patient-plan medication sync.
Connections. OUT: Contacts, Sales_Orders (patient plan), External_RXs. IN: Plan_Change_Logs related list. Encounter linkage is via Encounter_ID text rather than a CRM lookup because the ID originates externally.
Automation. 8 active rules — grouped by trigger:
- create: Update Refills in Plan, Update Order Status - Encounter Processed, Update External RX Module, Update Ext RX Pharmacy, Add New Pharmacy, Log Plan Content.
- field_update: Cleanup Workflow.
- date_or_datetime: Extract Data - Scheduled (periodic payload parsing).
Business role. Without Treat_Events the CRM cannot ingest prescription orders written outside its own UI — refill counts, pharmacy assignment, External_RX records, and patient-plan medication state would all drift from what was actually prescribed.
Purpose. The insurance-verification (VOB) ledger — one row per patient + insurance + service combination that recorded a benefits check: who is eligible, copay/co-insurance amounts, deductible standing, prior-auth requirements, in-network/out-of-network provider status, and verification date. Drives whether a service can be billed to insurance and what the patient owes.
Connections. OUT: Contacts, Insurance.
Automation. 9 active rules — grouped by trigger:
- create: Sync Contact to VS, Notify Contact Owner If Ad-Hoc Patient, Delete Empty Verified Service (cleans empty records after 1 hour).
- create_or_edit: VOB_Complete_Coinsurance, VOB Portal Notification.
- field_update: Update last verification date in insur and con, Sync MA Tags, MA Tags Nutrition/Life Coaching Eligible, Unable to Verify.
Business role. Without Verified_Services the billing team cannot tell what a patient's insurance covers — claims would be submitted blind, copays wouldn't be collected at booking, and MA-eligibility tags driving Nutrition/Life-Coaching routing disappear.
Purpose. The provider-to-service assignment matrix: which Books_Agent (provider) offers which Bookings_Service in which state and at which Service_Location, with per-pairing duration, blocked days, and channel flags. It is the schedulability table that the booking engine reads to figure out who can be booked for what, where, and when.
Connections. OUT: Books_Agents, Bookings_Services, States, Service_Locations. IN: Services_x_Contacts uses Service_Provider via Related_Services; Service_Locations carries reverse lookup back to Service_Provider; Bookings_Services lists it under related list "Bookings Services".
Automation. 5 active rules — grouped by trigger:
- create: Assign User, IS Alert When new service is created, Notify when service provider is added.
- field_update: Copy of Assign User, Notify when the WL Service is activated or deactivated.
Business role. Without Service_Provider, Bookafy/Bookings cannot determine which providers are eligible for a given service or state — scheduling collapses for telehealth-by-state services and provider assignments must be done manually for every booking.
Purpose. The licensing/credentialing registry for every state-provider pairing — which provider holds which type of license (NP, APRN, MD, DEA, etc.) in which state, expiration, pharmacy assignment per state for BHRT and Weight Loss, and license status. Critical for telehealth compliance because Thrivelab cannot legally see a patient in a state where the assigned provider isn't licensed.
Connections. OUT: States, Pharmacy (deprecated). IN: Insurance_Credentialing references it under "Licenses" related list.
Automation. 7 active rules — grouped by trigger:
- date_or_datetime: Payroll Notification-60, Payroll Notification-30, Payroll Notification-90 (license-expiration runway alerts).
- create: Update NPI in user, New DEA license added.
- create_or_edit: Support NP Cleanup.
- field_update: Trigger Support NP Cleanup.
Business role. If it disappears, the practice loses its single source of truth for which provider can legally treat patients in which state — telehealth bookings would have no compliance gate, expiring licenses would go unnoticed, and DEA/NPI sync to user accounts breaks.
Purpose. The roster module connecting a patient (Contact) to each staff member (Books_Agent) who has a role in their care — NP, PCA, MA, Life Coach, Nutritionist, etc. — scoped by service line and status (Pending/Recommended/Active/Declined/Paused/Opt Out). It is the "who is on this patient's team and in what state" table.
Connections. OUT: Contacts, Books_Agents (Staff), Encounters. IN: referenced by Services_x_Contacts automations that create/update Care Team rows on service enrollment.
Automation. 2 active rules:
- field_update: Update Contact Picklists — updates "Enrolled Services" and "MA Tags" picklists on the Contact when Care_Team status changes.
- create: Create_Additional_Services_Links.
Business role. Without Care_Team the system has no structured answer to "who on staff is responsible for this patient for this service?", breaking task routing, escalation logic, Contact-level enrolled-services rollups, and recurring-payment attribution.
Purpose. Despite the name (carried over from Zoho Books integration), this is the staff/agent master record — every NP, PA, MD, PCA, MA, Life Coach, RD, and IT/Leadership user who interacts with patients or supports the clinic. It carries each agent's role, title, credential, ID across Bookings/Meeting/Books platforms, SOAP-template snippets per gender, biography, notification preferences, OOO status, and equipment assignments.
Connections. Heavy fan-out — referenced by Encounters (Provider), Care_Team (Staff), Service_Provider (Provider), Care_Team_Connect (Reply_To), Equipment (Staff), and many more. OUT: Major_Payor_Contracts related list.
Automation. 6 active rules — grouped by trigger:
- create: assign_user (also create_or_edit), New Staff Added.
- create_or_edit: assign_user.
- field_update: Delete Services When Staff Is Inactive, Deactivate licenses.
- date_or_datetime: Send Provider Snapshot, Monthly Cancelation Report.
Business role. If Books_Agents disappears the practice has no staff roster — every Encounter's Provider lookup, every Care_Team assignment, every Service_Provider scheduling row, every equipment-asset link, and the per-provider SOAP templates evaporate.
Purpose. The master list of Thrivelab and partner-clinic physical addresses — the universe of "where could a patient be seen in person?" — distinct from Service_Locations (which ties addresses to specific provider-service pairings). Encounters carry a Clinic_Address lookup pointing here when the visit took place at a clinic.
Connections. OUT: States. IN: Encounters (Clinic_Address lookup), Contracts (related list), Major_Payor_Contracts. Defaults to "Active Clinics" view.
Automation. 1 active rule:
- create: send email to is when clinic is created (IS = Insurance Services notification when a new clinic is added).
Business role. If it disappears, Encounters cannot identify the physical clinic for an in-person visit, payor-contract address binding breaks, and the IS team loses the new-clinic alert.
Purpose. Patient-specific fitness/training intake and engine output — captures the patient's physical-activity level, workout experience, preferred workouts, home-gym equipment, available workout time, and the AI/engine-generated training and nutrition program outcomes. Note the typo in the module API name (Fitnes_and_Training, missing an "s").
Connections. OUT: Contacts, Intake_Form (Medical_Profile).
Automation. 1 active rule:
- create: Create App User and Update Nutrition and Training Data (provisions the patient in the training-app platform on form submission).
Business role. If it disappears, the Fitness add-on stops being usable — patients can't have personalized training/nutrition plans generated, and the training-app user provisioning step breaks at intake.
Purpose. The custom B2B/operational approval queue the practice built on top of Zoho's generic Approvals — distinct from the native module, this one is creatable/editable and carries domain-specific fields for Provider Update requests and Insurance Audit / B2B partner-onboarding intake (clinic name, type of clinic, billing address, NPI, areas of specialty in regenerative/peptides/aesthetics/hormone-health).
Connections. OUT: Contacts (Patient).
Automation. 1 active rule:
- create: Send Notification Approvals Pending.
Business role. If it disappears, the custom B2B partner-clinic onboarding intake and Provider-Update / Insurance-Audit approval pipelines collapse — staff lose their structured queue for reviewing partner clinics and provider-information changes, and the pending-approval notification stops firing.
Approvals · no Deluge code
This is Zoho CRM's built-in "My Jobs" module — the system approval queue (visible as "Approvals" in the UI). It is non-creatable/editable/deletable by users, has no custom fields, and surfaces approval tasks generated by Zoho's approval-process engine across the org (record-level approvals such as deal sign-offs, refund requests, etc.).
System-generated; not a CRM-modeled entity with lookups.
If this disappeared: If it disappears, Zoho's native approval-process feature is gone — managers can't approve/reject record changes routed through Zoho approval workflows. (In practice it does not disappear; it ships with Zoho.)
Bookings_Services · no Deluge code
The service catalog — every bookable service Thrivelab offers (Telehealth visit types, BHRT, Stem Cell, Regenerative, Nutrition, Life Coaching, Plan Review, Virtual Primary Care, Weight Loss Consult, partner-program consults, etc.) with its scheduling parameters, cost variants (insurance vs cash), required intake documents, and Bookafy/Bookings configuration.
If this disappeared: If it disappears, nothing is bookable — the practice loses its service definitions, durations, prices, intake-document requirements, and Bookafy/Zoho-Books mappings. Every patient-facing scheduling portal goes blank.
Care_Team_Connect · no Deluge code
A lightweight communications/notification entity used as a reply-to or routing endpoint for Care Team correspondence (the Reply_To lookup points to Books_Agents). It is structurally distinct from Care_Team (the patient-staff roster) and exists mainly as an email/notification handle.
OUT: Books_Agents via Reply_To.
If this disappeared: If it disappears, automated Care Team emails lose their structured reply-to channel — communications still send, but threading and from/reply-to identity for Care Team correspondence become inconsistent.
Contact_x_Services · no Deluge code
A second contact-to-service junction module — the layout title is literally "delete" and the API name Contact_x_Services together with the directional name suggest this is the older / deprecated duplicate of Services_x_Contacts. It links Contacts (via the field oddly named Booking_Services) to Bookings_Services (via TL_Service_Lookup). No payment-type, no portal-link, no automations attach to it.
OUT: Contacts, Bookings_Services.
If this disappeared: Honestly: this looks like a legacy/deprecated duplicate of Services_x_Contacts kept for historical data — the layout label "delete" plus the absence of automations strongly suggest it's slated for removal. If it disappears, nothing active breaks; if it has stale data, that data is silently invisible to the SxC-driven workflows.
Equipment · no Deluge code
Staff equipment / asset register — laptops, monitors, keyboards, headsets, mice, trackpads issued to Books_Agents with serial numbers, purchase dates, OS, RAM, storage, and observations. Operations/IT module rather than clinical, but it sits adjacent to Books_Agents and is included in the clinical-care perimeter because staff equipment provisioning is part of new-provider onboarding.
OUT: Books_Agents (Staff).
If this disappeared: If it disappears, IT loses its staff-asset ledger — equipment-to-staff attribution, replacement tracking, and offboarding return checks all become manual.
Home_Visit_Info · no Deluge code
The structured intake / physical-exam record for an Initial (Home) Visit — captures height/weight, head-to-toe normal/abnormal exam findings (HEENT, lungs, heart, abdomen, neuro, extremities, breast, thyroid), draw-blood flag, lab selection, and SOAP-style narrative fields. Despite the API name "Home_Visit_Info" the layout title is "Initial Visit Info" — used for the first in-person/home assessment that precedes BHRT/Stem Cell enrollment.
OUT: Contacts.
If this disappeared: If it disappears, the practice loses its structured initial in-person assessment, the Contact-level "HV Complete" flag stops updating, server-side data push for home visits breaks, and patients can't be cleared into BHRT/Stem Cell programs that require an initial physical.
SOAP_Writing_Suggestions · no Deluge code
AI-assisted clinical documentation review — each row stores model output critiquing a specific Encounter's SOAP note: missing elements, suggested rewrites, severity rating, and writing tips. Generated to help providers improve note completeness before locking.
OUT: Encounters.
If this disappeared: If it disappears, providers lose AI-assisted note-quality feedback inside the CRM; SOAP documentation still functions, but coaching/audit assistance vanishes.
Service_Locations · no Deluge code
Physical service-delivery addresses tied to specific Service_Provider rows — used when a service is delivered at a clinic, home, partner location, etc. Each row carries a structured address tied to a state and a service-provider pairing.
OUT: Service_Provider, States.
If this disappeared: If it disappears, in-person service routing loses its address inventory — home-visit, clinic-visit, and regenerative-medicine in-person services lose their delivery-address dictionary.
Trainers · no Deluge code
Reference list of fitness/training engine providers integrated with the practice's Fitness add-on — each row points to an external trainer-platform entity (likely the Hi5/training partner that powers the Fitness add-on for TransformNation patients). Tiny module: just an ID, an entry point URL, and an assessment-type tag.
IN: Enrolled_Services (Trainer lookup), Membershi_X_Trainers (add-on junction), Suscription_Payments.
If this disappeared: If it disappears, the Fitness add-on cannot be attributed to a training-platform provider — patient Enrolled_Services lose their trainer assignment and the add-on linkage to billing/payments breaks.
Visits · no Deluge code
A Zoho-native page-tracking module recording portal/website page visits (Visited_Page, IP, browser, ad attribution) — not clinical visits despite the name. It is a marketing/visitor-tracking facility, distinct from Encounters which represent completed clinical visits and from Bookafy/Bookings appointments which represent scheduled ones.
Read-only system module — not creatable/editable/deletable by users.
If this disappeared: If it disappears, marketing loses funnel attribution for portal pages and paid-ad landings; clinical operations are unaffected because clinical visits live in Encounters.
Vital_Signs · no Deluge code
Structured vitals record — one row per measurement set (BP, pulse, respiration, temperature, oxygen saturation, height, weight, BMI, waist/head circumference) captured during or attached to a clinical interaction. BMI is a calculated formula. Free-standing module with no native lookup back to a Contact or Encounter (vitals likely linked through subform or related list elsewhere in practice).
If this disappeared: Holds the structured numeric clinical observations independent of narrative SOAP notes. If it disappears, structured vitals reporting/trending is lost; the clinic falls back to free-text Objective fields inside Encounters.
Weightloss_Forms · no Deluge code
The structured weight-loss intake (and follow-up) questionnaire — by far the largest of the clinical-intake modules (122 fields). Captures eating habits, exercise patterns, alcohol/tobacco/caffeine use, comfort foods, dietary restrictions, weight history (CW/HW/LW/Desired with age stamps), motivations, methods previously tried (Calorie tracking, Weight Watchers, Intermittent Fasting, GLP-1, Bariatric, etc.), and a nutrition-engine outcome. Driven from a JotForm wizard.
If this disappeared: If it disappears, the weight-loss program loses its structured intake — BMI computation, patient-plan derivation, contact tagging, training-app user provisioning, and lead-email capture for WL leads all break.
This is the financial and clinical spine of Thrivelab's CRM — the place where every patient's signed treatment program lives, gets audited, billed, modified, and (eventually) cancelled or renewed. The center of gravity is Sales_Orders (the "Patient Plan"), a 247-field super-module governed by 125 active workflow rules that orchestrate the full life of a hormone, weight-loss, peptide, or stem-cell protocol: pre-draft, NP approval, CCO review, audit, patient signature, recurring invoicing for both medication and platform fees, refill counters, plan modifications, pauses, escalations, and cancellation reason coding. Surrounding it are the proposal/draft layer (Plan_Proposals, Plan), the compliance and change-history layer (Plan_Audits, Plan_Change_Logs), the upsell layer (Plan_add_ons, Additional_Recs, Clinical_Assistant_Recs), the AI-and-NP-classified clinical recommendation engine (Recommendation, RecommendationsRE), the stem-cell pre-qualification + financing track (Stem_Cell_Assessment, Longevity_Installments, Layaway_Plans), the e-commerce shop track (Shopping_Cart, Shop_Cart_Item), the membership/portal pricing track (Membership_Options, Portal_Pa_X_Membershi), and the marketing/loyalty surface (Coupons, Giveaways, Loyalty_Items, Wallet, TTP). Deals and Quotes are the pre-Patient-Plan funnel artifacts that get superseded once a Patient Plan is signed.
Purpose. Sales_Orders is the Patient Plan — the single signed, billable treatment program record per patient (one patient typically has multiple over time as plans get modified, paused, restarted, or replaced). It is the most automated and most-referenced module in the entire CRM: 247 fields, 125 active workflow rules, 32+ other modules link into it. It carries the full clinical context (assessment scores, labs, ICD-10 codes, symptoms), the regulatory context (NP, DEA, NPI, supervising physician, prescription signatures), the financial context (meds recurring invoice, platform-fee recurring invoice, last invoice status, refills remaining), the fulfillment context (delivery preference, external pharmacy, last order/last delivery dates), and the lifecycle context (~30 status values from Pending through Plan Approved to Plan Paused, Retention Journey, Cancelled).
Connections.
- Out: Contact_Name → Contacts; Pharmacy_Fax_number → Pharmacy; Patient_Name → Lab_Orders; ICD10_Codes (multiselect) → ICD_10_Codes via Patient_P_X_ICD_10_Co.
- In (related lists, 32+ modules): Plan_Proposals (Main_Plan), Plan_Change_Logs (Patient_Plans), Plan_Audits, RecommendationsRE (Recommendation Engine), Additional_Recs (Additional Recommendations), Medication_Order_Test (Active Medications), Supplement_Order, Treat_Events (Prescriptions History), PO (Shipment History), Fulfillment_Requests, Fulfillment_Queue, Orders_Processed, Lab_Orders (Patient_Plan1), Lab_Order_Request, Invoices, Encounters, Shipment_Requests, External_RXs, Early_Refill_Requests, Weightloss_Forms, Cases/Support, Chats, Medical_Conditions, Medical_History, Surgical_Procedure, Patient_Medications, Patient_P_X_Payment_M.
Automation. 125 active workflow rules — the most automated module in the system. Major clusters:
- Status state machine. A dense set of rules (Update Status Based On NP Approved, Update Status Based On CMO Reviewed, Update Status Based On CMO Questions, Update Status Based On Plan Stopped, Update Status Based On Plan drafted, Update status Based On Plan Review Scheduled, Plan_Review_Scheduled_status_update_edit, Audit_Complete _date_status_update (+ edit variant), PLA-PAT-T010 Update Status to Plan Review Complete, PLA-PAT-T011 Update Status to Patient Approved (create and field_update), PLA-PAT-T032 update status when plan started updte, Update Status to Patient Approved) keeps Status synchronized with every approval-date field as it gets stamped.
- Approval workflow tasks. PLA-PAT-002 Create_Task_when_PPDraft_isnot_Empty, Creat_task_ScheduleReview, Create task Pending PCP, PLA-PAT-T006 When CCO Questions field not Empty, CCO Plan Review, Audit plan task, PLA-PLA-S001 Plan Review Audit Task, Update NP Approved when Doctor reviewed, Update NP data, PLA-PAT-S003.1 (Graduated Providers shortcut), Plan Started Task, Labs Due Task, 3M labs imported task, DPC follow up - Reassign Contact to DPC.
- Plan-modification machinery. Modification of Plan - Field Reset (increments Plan_Version, clears CCO Reviewed / NP Approved / Audit Complete, resets Patient_Plan_Draft), Modification of Plan - Update Recurring Invoices (rewrites meds RI + creates Optum RI + adds HR Log), NewPlanVersion,ReplaceRecurringInvoice.updateMsupp, Update Patient Cycle Started and RE feedback loop.
- Billing automation. Associate Card To Recurring Invoice, PLA-PAT-T016-17 Create Task Manual Check Invoice, Create Subs Recurring Invoice - Today (Thrive Optum), on create - CreateInvoiceWhenPlanApprov, Create Purchase Order (when invoice paid & warehouse ≠ thrivelab).
- SMS & email triggers. PLA-PATS001 PatientPlanDraftedfieldNotempSendSMS, Email gender-specific patient plan presentation, Attach Prescription Plan at Real Time, attach signed prescription temp with module, Task to send prescription order to Pharmacy, Update RX Expiration Date.
- Sync rules. Sync_fields_of_Contact_and_PatientPlan2, Sync fields of patient plan with contact, Patient Plan Updated Workflow, add DPC calendar and DPC contact owner full name, Assign Contact Owner on Plan Approved - PC Journey, Dates_and_Checks_fields_update2.
- Scheduled jobs. create task when plan appr. date is 70 days ago, Plan Started Task, Missing Payroll Information, PLA-PLA-S001 Plan Review Audit Task. The full list runs to roughly half of the 125 rules and continues with retention-journey, exit-blueprint, BHRT/WL portal approval, support-NP, prescription-expiration, refill-counter, lab-due, and AI-audit handlers.
Business role. This is the signed treatment program. If Sales_Orders stops functioning, no patient gets billed for medications or platform fees, no NP/CCO approval chain runs, no prescription template is produced, no recurring invoice is created or updated, no plan modification or cancellation is auditable, and no fulfillment can be triggered — the entire revenue and clinical-compliance engine of Thrivelab is offline.
Purpose. Labeled "Stem Cell Plans" in the layout — the master record for a stem-cell / longevity treatment program. Carries the contract status, deposit + cash + financing breakdown, the panel of therapy options (Left Knee, Right Hip, Hair Restoration, Systemic Therapy, etc.), the scheduling of consultation / treatment / follow-up, the b2b shipping fields for non-treatment orders, and the cross-link to a Layaway_Plans record if financing was elected.
Connections. Out: Contact → Contacts, Encounter → Encounters, Lead → Leads. In (related lists): Encounters, PO Forms (Stem_Cell_Plans), Layaway_Plans.
Automation. 19 rules — heavy lifting for the stem-cell sales process:
- Pricing/financing: Final Price and Suggested Price, Sync Layaway Amount, Remaining Balance.
- Invoicing & contracts: Initiate Installment Schedule - Longevity Installments, Invoice Date - Longevity Installments , Invoice Status Update - Longevity Installments, Payment Reminder - Longevity Installments , Sync Signed Date - Longevity Installments, Create B2B Invoice , Submit Order to Precision Biologics.
- Patient journey: Send Contact to Nawi - Longevity Installments, Sync_Encounter, Add SC Notes to Contacts, Send Patient Quality of Life Form , US Stem Cell Emails , Therapy Tips , Cancel Appt Task , Minoxidil Needed Subsequent Plan Task, Cleanups.
Business role. The financial + clinical record for everything stem-cell at Thrivelab — package configuration, contract signing, deposit / cash / financing collection, Costa Rica logistics, b2b shipping (e.g. to Precision Biologics), and the post-treatment follow-up cadence.
Purpose. The patient-portal / web-shop cart — collects products into an order, calculates totals, applies a coupon if any, holds the shipping address, and on payment generates a Zoho Books invoice and converts to placed orders (a recurring 30-day option exists alongside one-off).
Connections. Out: Contact → Contacts, Coupon → Coupons. In: Shop_Cart_Item (line items), Cart_Status_History, Supplement_Order.
Automation. 3 rules — Place Orders on Paid, Abandoned Cart - Email Reminder , Create Task for Provider.
Business role. Patient-portal e-commerce checkout — primarily for supplement reorders, scale/tape add-ons, and one-off product purchases that don't go through the Sales_Orders subscription flow.
Purpose. Pre-qualification questionnaire for stem-cell / longevity treatments. Captures the patient's clinical concern, pain level, prior treatments tried, medical conditions, treatment goals, expected payment method, and credit-score self-estimate — used to filter the stem-cell funnel (these treatments cost $25K+ and aren't insurance-covered, so financial qualification matters as much as clinical fit).
Connections. Out: Lead → Leads, Contact → Contacts. In: none.
Automation. 5 rules — Assessment Completed Existing Patient/Lead (on create, routes to the right path), Add info to lead (sync answers back to the originating Lead), Trigger SMS Stem Cell WF (on create, kicks off SMS journey), Trigger US Stem Cell Journey , SMS Journey (scheduled drip).
Business role. The financial-and-clinical gate that pre-qualifies stem-cell prospects before sales spends time on them — credit-score and payment-method capture is as important as orthopedic injury site, because the financing offer determines whether the deal can close.
Purpose. Payment-financing mechanism for stem-cell treatments — splits the patient's Longevity_Installments total into 2–12 monthly invoices and tracks completion percentage, remaining balance, and DPC notifications at key milestones (50%, 60%, last invoice). Pairs with a Zoho Books recurring invoice that auto-bills the patient each month.
Connections. Out: Stem_Cell_Plan → Longevity_Installments. In: surfaced on Longevity_Installments as related list.
Automation. 4 rules — Sync Status to SC Plan (mirrors layaway status onto Longevity_Installments), Update Status, Stop RI (stops the recurring invoice on cancellation/completion), Book Appt Alert.
Business role. Lets the stem-cell sales team close patients who can't pay $25–50K cash up front by financing the treatment over 2–12 months — critical for stem-cell deal closure rates since these treatments are not insurance-covered.
Purpose. A historical diff log: every meaningful edit to a Patient Plan's product/dose list is written here as a snapshot of "what the plan contained, what changed vs the previous version, when, and tied to which prescription event."
Connections. Out: Patient_Plan → Sales_Orders, Treat_Event → Treat_Events. In: none.
Automation. 1 rule — Send Email Temp notifies stakeholders when a change is logged.
Business role. The non-repudiation history for plan content; lets the clinical and ops teams answer "what exactly did this patient's plan look like on date X?" without trusting the current Sales_Orders state.
Purpose. Per-patient credit / debit ledger powering Thrivelab's loyalty + referral rewards. Each row is one ledger entry (Credit or Debit), optionally tied to an invoice or credit note, optionally auto-applied to the next invoice. Used to credit patients for referrals (From lookup to the referring Contact / Lead), apply coupon-driven credits, and debit balance when redeemed.
Connections. Out: Contact → Contacts, Referred_By → Contacts, From_Lead → Leads. In: none direct (read by automation on Contacts and Invoices).
Automation. 5 rules — RewardPoints-Trigger Point calc in 5 minutes (on create, kicks off point calc), RewardPoints-Total Points Calculation (scheduled rollup), RewardPoints-Total Points Calculation-deleted rec (on delete, recompute), Auto Apply Initial Credit -legacy, Delete credit note.
Business role. Money-like reward + referral-credit ledger powering Thrive Together (referral-bonus) credits, coupon free-month credits, and any other patient-account adjustments — the source of truth for "how much credit does this patient have."
Purpose. Thrive Together Program — Thrivelab's patient-to-patient referral form. When an existing patient refers a friend, this record links the referrer Contact to the referee Contact and stores the unique referral link used. Wallet credits flow from this referral relationship.
Connections. Out: Contact → Contacts (referrer), Referee_Contact → Contacts (referee). In: none direct (consumed by Wallet automation).
Automation. 2 rules — createrecordinTTPmodule (on create, generates the linking record), Fix links (on field_update, repairs broken referral URLs).
Business role. The referral-program ledger linking referrer and referee Contacts; pairs with Wallet to credit the referrer once the referee converts to a paying patient.
Additional_Recs · no Deluge code
Free-text additional-recommendation rider attached to a Patient Plan — used by providers to record extra suggestions that don't fit into the structured RecommendationsRE or the Sales_Orders subform.
Out: patient_plan → Sales_Orders.
If this disappeared: Unstructured upsell / extra-recommendation note attached to a plan — useful for things the structured engine doesn't model.
Clinical_Assistant_Recs · no Deluge code
AI-generated ICD-10 inferences for an encounter — the clinical-assistant model proposes diagnosis codes from the encounter text, and the module tracks how many codes the AI recommended vs how many the provider ultimately used and how much they overlap (a coverage / accuracy metric for the AI assistant).
Out: Encounter → Encounters.
If this disappeared: Quality/accuracy tracking for the AI clinical-coding assistant; used to evaluate whether the model's ICD-10 suggestions are good enough to lean on.
Coupons · no Deluge code
Discount-code catalog — defines a coupon code, its discount percentages broken down by product line (ITH, Meds, Subscription, Shop, Meetings, Stem Cell, Weight Loss), redemption limits, optional gender targeting, optional "free months" benefit, and a flag distinguishing patient coupons from influencer coupons.
Out: none.
If this disappeared: Promotional discount engine spanning every product line; supports both customer-facing one-time promos and ongoing influencer affiliate codes with broad redemption.
Deals · no Deluge code
The pre-conversion sales-pipeline record — created during Lead conversion to track the deal through stages until it either closes won (a Sales_Orders is created and the patient is paying) or closes lost. Carries the full ad-attribution payload (GCLID/AdGroup/Keyword/etc.) and a duplicate of the lead's intake-survey answers so the conversion stays self-contained.
Out: Contact_Name → Contacts, Campaign_Source → Campaigns.
If this disappeared: The funnel/pipeline view for sales reporting and Google Ads conversion attribution; once a deal closes won, the operational center of gravity moves to Sales_Orders and the Deal becomes a closed historical record with attribution context.
Giveaways · no Deluge code
A landing-page raffle / giveaway capture — collects entries (first name, last name, email, Instagram, what treatment they're interested in, would-they-buy-anyway flag) so marketing can run promotional giveaways for stem-cell or peptide treatments.
Out: none.
If this disappeared: Marketing lead-gen for paid giveaways / contests — standalone capture form, downstream conversion into Leads/Contacts handled outside this module.
Loyalty_Items · no Deluge code
Reward catalog — defines what a patient can redeem Wallet points for (item name, point cost, monetary value).
Out: none.
If this disappeared: Reward-redemption menu paired with the Wallet point system.
Membership_Options · no Deluge code
Catalog of paid memberships / portal access plans (Nutrition, Trainer, BHRT add-on, Peptides, VPC, TransformNation, etc.) — each row defines a price, recurrence, who it's available for, and which portal page it unlocks.
Out: Accessible_Portal_Page → Portal_Pages (m:n via Portal_Pa_X_Membershi).
If this disappeared: Pricing / access-tier catalog for the patient-facing portal — defines what each membership tier costs and what content/pages it grants access to.
Plan · no Deluge code
Plan is the original/legacy patient-plan module — 202 fields with a near-identical schema to Sales_Orders (same status values, same lab fields, same RI fields, same self-assessment subform) but used as the template/initial-plan layer before Sales_Orders became the active record. The presence of cross-links (a Plans lookup to Contacts, no incoming references from the rest of the active automation, only system custom views) plus the broader and more granular Sales_Orders superset strongly suggests this is the predecessor module preserved for historical data, with Sales_Orders now serving as the live "Patient Plan."
If this disappeared: Legacy / historical Patient Plan store — kept for old records and referenced by the schema's "Plan vs Sales_Orders" split; new operational activity happens on Sales_Orders.
Plan_Audits · no Deluge code
A compliance / quality-assurance log: when an auditor (or the AI audit) finds an error on a Patient Plan — wrong dosage, wrong medication amount, missing follow-up — a Plan_Audits record is created, classified, and routed to the responsible team (Provider or Fulfilment).
Out: Patient_Plan → Sales_Orders.
If this disappeared: Auditable evidence trail for plan-level clinical or billing errors; required for regulatory hygiene given the controlled-substance / GLP-1 medication mix Thrivelab dispenses.
Plan_Proposals · no Deluge code
Pre-signature plan-update drafts. When the CCO/Patient Care Journey team wants to propose a price reduction, payment-option change, or supply change (e.g. switching the patient from monthly to 3-month upfront), they build a Plan_Proposal showing current vs new plan side-by-side, send it to the patient for acceptance, and on acceptance the changes flow back into the underlying Sales_Orders.
Out: Patient_Plan → Sales_Orders, Contact → Contacts.
If this disappeared: The patient-facing negotiation surface for revising an active plan — handles savings math, sign-off, and the email cadence that nudges the patient to accept before the next invoice date.
Plan_add_ons · no Deluge code
Captures à-la-carte upsells attached to an active patient (e.g. the "Scale & Body Tape" add-on for weight-loss patients). Each record is a small one-off invoice line that gets its own Books invoice and is marked complete once paid.
Out: Contact → Contacts.
If this disappeared: Lightweight standalone-charge mechanism for selling accessories or one-off items to existing patients without modifying their main Sales_Orders subscription.
Portal_Pa_X_Membershi · no Deluge code
Many-to-many junction module between Portal_Pages and Membership_Options — answers "which portal pages does this membership unlock?" or equivalently "which memberships grant access to this page?"
Out: Accessible_Portal_Page → Portal_Pages, Addon → Membership_Options.
If this disappeared: Pure linking module for portal access control / membership-driven content gating.
Quotes · no Deluge code
Standard Zoho CRM quote module — a formal-looking quotation document that can be generated from a Deal, sent for signature, then converted into a Patient Plan. Largely the out-of-the-box module; doesn't appear to carry much custom Thrivelab logic.
Out: Deal_Name → Deals, Contact_Name → Contacts, Account_Name → Accounts.
If this disappeared: Lightly used; the standard CRM quote-to-order capability that some sales flows produce before the Patient Plan is created. Most of Thrivelab's quoting effectively happens through Plan_Proposals instead.
Recommendation · no Deluge code
Older clinical-recommendation module — captures NP / Medical Director / CCO sign-off on a recommended set of supplies for a patient, with a single "ADDITIONAL SUPPLIES" subform and a summary finding text block.
Out: Patient → Contacts.
If this disappeared: Legacy / supplement-style recommendation log — predecessor to the active RecommendationsRE engine. Mostly inert today.
RecommendationsRE · no Deluge code
The current AI-and-NP recommendation engine — paired with Sales_Orders via Patient_Plan and with Self_Assesments. Generates an "AI Initial Recommendation" subform from the patient's hormone/lab inputs, then captures the NP's "Final Recommendation" subform, classifies it, computes how closely the two match (Initial_Match %, Final_Match %, Match_Count), and flags discrepancies for AI-audit review. The "RE" suffix = Recommendation Engine, the modern reasoning-engine replacement for the older Recommendation module.
If this disappeared: The clinical decision-support layer: AI proposes a medication mix from the patient's assessment, the NP either accepts or overrides, and the system tracks the agreement rate per provider/patient as a quality metric and feeds AI-audit escalations.
Shop_Cart_Item · no Deluge code
Line items of a Shopping_Cart — one record per product per cart.
Out: Shopping_Cart → Shopping_Cart, Product → Products.
If this disappeared: Junction table giving Shopping_Cart its line-item structure.
Solutions · no Deluge code
Out-of-the-box Zoho "Solutions" (FAQ / knowledge base) module — Solution_Title, Question, Answer, Product_Name → Products. Effectively unused or lightly used as a knowledge-base, not part of the financial flow.
Out: Product_Name → Products.
If this disappeared: Standard Zoho solutions/FAQ table — present but not load-bearing in Thrivelab's plans-and-sales operations.
This domain captures everything Thrivelab does to assess, diagnose, and clinically validate care: lab orders and results (hormones, vitamins, STI, comprehensive panels), diagnostic imaging, vaccines, surgical history, and referrals to outside specialists. It also houses the coding vocabularies (ICD-10 diagnosis codes, CPT procedure/billing codes) used to attach medical justification to every clinical artifact for both insurance billing and clinical-decision-support logic. Finally, it includes the AI-augmented review layer (AI Audit Request, AI Output, AI assistant chats, Self Assessments) and the medication-grouping reference used by safety/compliance audits to detect risky polypharmacy across the peptide, hormone, weight-loss and longevity programs.
Purpose. The patient-facing structured self-report questionnaire - symptoms, lifestyle, goals, family history, vitals, and BMI - used to compute hormonal-imbalance scores (Thyroid, Estrogen, Progesterone, High/Low Testosterone) that drive recommendation engines and provider routing. The complement to AI_assistant_chats: instead of free-text chat, it's a deeply structured symptom-and-history form.
Connections. IN: submitted via patient portal/forms. OUT: -> Contacts (Patient), -> Leads (Lead). Related lists RecommendationsRE, RSA (legacy SA store).
Automation. ~30 active rules including Update_Subform_calculs, subformData_inPatientPlan, update_patientPlanWith_SA, count_point and SA action item, Update_contact_selfAssesment_date (x2), Twillio SMS - Self Assessment Recurring P2, update Date_of_Last_Menstrual_Cycle, sequential number for each assessment, Add imbalance Score, auto close SA follow up task, create_sales_orders, sync data with Plan module, SNP-Plan Modification, SNP - Rec Summary, BMI_Flags_for leads, Sync_new_SA_data, Tag patient if reports Diabetes, clean_bmi_cal_leads, SA_Completed_Email_Template, Check SA to see if DEA is needed, DPC_Semaglutide_Task, Update_MA_tags, RSA 2.0 - Appointment Follow Up, Update Gender, Provider Task, RSA Cleanup, History of Cancer Task - SA, Close Outdated task, Update MA Tag and BMI for contacts, Add Self Assessments Notes to Contacts, No Medical Services Check, History of Cancer and Create App User and Kept User from SA.
Business role. The central structured-symptom intake that feeds every downstream clinical decision - plan creation, lab orders, recommendations, DPC tasks, and provider routing.
Purpose. The master record for any blood/urine/saliva panel a provider has ordered for a patient. It tracks the full lifecycle from "lab req needed" through draw, courier tracking, invoicing, importing of results, and NP review, including vendor selection (LabCorp, Quest, Sonora Quest, Ayumetrix home kit, etc.) and the chosen payment path (insurance vs. Thrivelab vs. patient-paid).
Connections. IN: lookup from Kit_Ayumetrix.Lab_Order, Ayumetrix_orders_queue.Lab_Order, Lab_Req_info.Lab_Order; related list of Lab_Order_Tests ("Test"); ICD linkage via Lab_Orders_x_ICD10_Codes. OUT: -> Contacts (Contact_Name), -> CRM Users (Nurse_Practitioner). Also feeds Lab_Order_Status_History.
Automation. Highly automated, ~30 active rules including UpdateCreatedDate, Update status to lab req sent, UpdateStatus Labs Imported, Sync contact fields from Contact Module, Notify PCC-Labs Completed, Lab Invoice Paid Actions, Lab_paid_send_lab_req, Classify_lab_rec, active_lab_req_process_15_days_before, Task_for_PCC_if_labs_not_completed (+ empty-LDD variant), Lab_data_collection_confirmed_LDD/NLDD, attach_lab_req, Ayumetrix_queue / Ayumetrix_queue_delete, Insurance Email - Labs, Pending Payment Pref - 5 days Before Due Date, Update Tracking Data, Tracking Number Note and Home lab kit notification, SMS lab reminder, SMS lab results, Return Label Tracking Note, Action Item - Labs on Time, additional_lab_costs (+ accepted variant), Last RX - Lab Req, NP Added Notes Actions, Task - Check sample viability, bill to, lab preference.
Business role. The operational backbone of Thrivelab's diagnostic process - every hormone, peptide, weight-loss, or longevity protocol depends on a Lab_Order moving cleanly from req-creation through imported results before therapy decisions are made.
Purpose. Captures the lab requisition / result document metadata after a draw: requisition number, collection/received/reported timestamps, fasting flag, status (Partial/Incomplete vs. Final/Complete), and a subform of individual marker results. Effectively the "lab report received" record tied back to a parent Lab_Order.
Connections. IN: created by sync-from-lab-vendor automations. OUT: -> Lab_Orders (Lab_Order), -> Contacts (Contact_Name), -> Books_Agents (added_by).
Automation. sync_lab_results (on create - propagates results to the parent Lab Order and downstream records), Partial Results - Update Lab Order (status sync when only some markers come back), Lab Results - Reset Blueprint (re-opens Lab_Order workflow state when a new result arrives).
Business role. The "results inbound" record that closes the loop between an ordered lab and the data the provider reads.
Purpose. A conversation record between a patient/visitor and Thrivelab's website AI assistant. Stores thread/session metadata, visitor analytics (landing page, current page, past visits, IP, city/state), and links the chat back to a Contact or Lead once identification happens.
Connections. IN: created when a visitor opens the assistant. OUT: -> Contacts, -> Leads. Related list to AI_assistant_messages (per-turn messages).
Automation. Sync lead or contact (on create - matches the chat to an existing Lead/Contact by phone/email).
Business role. The session-level container for AI-assistant conversations on the Thrivelab website, used for lead capture and conversion attribution.
AI_Audit_Request · no Deluge code
Captures a clinician's documented change to a patient's plan, treatment, or chart along with the evidence basis (ITH data, intake-form data, self-assessment data, DPC notes, lab markers, medical advice). It is the structured input for the AI clinical-chart audit that flags whether the change is justified and properly documented.
IN: created from the chart-audit wizard.
If this disappeared: The structured form that turns a free-text clinician decision into a machine-auditable record for compliance review.
AI_Output · no Deluge code
The AI's structured recommendation output - what medication / supplement / Medpax to dispense for a given clinical imbalance, with dosage references and DEA-controlled flag. It is the materialised output of the AI rules engine that providers can review before approving.
IN: generated by the AI service.
If this disappeared: The persisted AI-suggested recommendation that bridges clinical reasoning and the dispensable product catalog.
AI_assistant_messages · no Deluge code
Per-turn message log for an AI assistant chat - one record per user or assistant utterance with the full message text and timestamp.
IN: written by the assistant integration on each turn.
If this disappeared: Full transcript storage for AI assistant conversations - reviewable by staff and used for QA/training.
Audit_System_Med_groups · no Deluge code
A reference grouping of medications used by the safety / compliance audit system to detect risky combinations or polypharmacy patterns. Each record represents a medication-group definition (its members are stored in the Medications1 subform).
Referenced by the compliance/audit logic that scans patient med lists; no inbound lookups from clinical modules.
If this disappeared: The static medication-group lookup that the AI audit and safety-flag rules read when classifying a patient's combined prescription/peptide regimen.
Ayumetrix_orders_queue · no Deluge code
A queue/staging table for Lab_Orders that have been routed to the Ayumetrix home-kit fulfilment pipeline but have not yet had a Kit_Ayumetrix shipment created. It is the bridge between "Lab Order tagged Ayumetrix" and "kit physically ordered."
IN: populated by Lab_Orders.Ayumetrix_queue workflow when a Lab Order's Lab_Req becomes "Ayumetrix queue"; removed by Ayumetrix_queue_delete.
If this disappeared: The "to-ship" worklist that ops uses to batch-process at-home kit orders.
CPT_Codes_Data · no Deluge code
The catalog of CPT (Current Procedural Terminology) procedure/billing codes - the "what was done" pair to ICD's "why it was done." Each row is a CPT code with description and a default price, used to drive insurance billing and patient invoicing.
Referenced by IT_Test (Main_CPT_Codes, Additional_CPT_Codes picklists) and by claims/billing logic on Encounters / Sales_Orders.
If this disappeared: The procedure-code dictionary required to bill insurance and price every clinical service in the system.
External_Referrals · no Deluge code
Outbound referrals from Thrivelab providers to outside specialists (cardiologist, endocrinologist, oncologist, etc.). Captures the specialist's contact info, reason for referral, supporting documents to send, urgency, and the diagnosis codes that justify the referral.
IN: created from Encounters.
If this disappeared: The outbound-specialist referral packet generator and tracking record.
ICD/Lab Junction Modules
ICD_10_Codes · no Deluge code
The canonical diagnosis-code reference table. Every record is one ICD-10 code (e.g., E55.9 Vitamin D deficiency) with description, severity, and a medical category (Endocrine, Mental and Behavioral, Musculoskeletal, etc.). Used by both billing automations and the AI clinical-decision logic.
IN/OUT junctions: Encounters_X_ICD_10_Codes (-> Encounters), Patient_P_X_ICD_10_Co (-> Sales_Orders), Medication_Order_Test (related list "ICD10 Codes").
If this disappeared: The diagnosis vocabulary that justifies every medication, lab, imaging study, and referral for both clinical reasoning and insurance billing.
ICD_10_Codes_for_VPC · no Deluge code
A parallel ICD-10 reference set scoped to the VPC (Virtual Primary Care) program. It mirrors the structure of ICD_10_Codes but is the vocabulary used specifically by VPC-tagged modules (Imaging_Labs, External_Referrals, VPC_Lab_Order, Vaccine_Order) so the VPC clinical workflow can carry its own curated code set without polluting the main ICD list.
If this disappeared: Keeps the VPC product line's diagnosis vocabulary curated and decoupled from the broader CRM's ICD master.
IT_Test · no Deluge code
Despite the generic API name, this module is the encounter-style record for the "Internal Test" / virtual care visit type that lives between a self-assessment and a full Encounter. It carries the appointment, the staff member, meeting type (Initial Telehealth, Weight Loss Consult, Nutrition Coaching, Virtual Urgent Care), the chosen CPT billing codes, and a Blueprint (status machine) used for routing.
IN: created from booking flows.
If this disappeared: The lightweight "internal/virtual visit" record that ties a staff appointment, billing codes, and kit fulfilment to a patient.
Imaging_Labs · no Deluge code
A full diagnostic-imaging order: X-Ray, Ultrasound, CT, MRI, Nuclear Medicine, Mammography, DEXA, Fluoroscopy, and Interventional Radiology. Captures contrast/sedation requirements, prior-auth status, reason for imaging and preferred result-delivery method - everything a referral imaging center needs.
IN: created by provider during an Encounter.
If this disappeared: The single record that turns a provider's "needs an MRI" decision into an actionable, coded order with insurance prior-auth.
Kit_Ayumetrix · no Deluge code
The shipped at-home dried-blood-spot collection kit record from Ayumetrix (a specialty home-lab vendor). Tracks the physical kit shipment to the patient (carrier, tracking, ship date) and the return shipment back to the lab.
IN: triggered from a Lab_Order that selected "Home Kit / Ayumetrix queue".
If this disappeared: The fulfilment + return-shipping ledger for Thrivelab's at-home Ayumetrix dried-blood-spot lab kits.
Lab_Order_Request · no Deluge code
A lightweight pre-order intake that captures the patient/plan-level intent to draw labs before a full Lab_Order is constructed. It is the link between the patient's Plan (Sales_Orders) and the eventual lab requisition, holding due date, lab vendor preference, and any additional diagnosis codes the patient wants billed.
IN: created from Patient Plan workflows.
If this disappeared: The "intent to draw labs" form that bridges the patient's purchased plan and the operational Lab_Orders pipeline.
Lab_Order_Tests · no Deluge code
A reference catalog of every individual test/panel Thrivelab can order, with vendor-specific test codes (Quest, LabCorp, Sonora Quest, Standard / Generic Insurance Form) and the canonical Test Name. It is the master list that drives multiselect fields and the panel-building UI on Lab_Orders and VPC_Lab_Order.
IN: referenced as a Related List "Test" on Lab_Orders.
If this disappeared: The single source of truth for what a "panel" or "test" means across every lab vendor Thrivelab uses.
Provider_Referral · no Deluge code
The inverse of External_Referrals - this is for Thrivelab-internal provider referrals (a DPC routing a patient to a Life Coach / Nutrition Coach internal provider, or noting a referral coming in from a PCP). It is a lightweight intra-system referral record, often urgent, with a meeting-booking follow-up loop.
IN: created from Encounters or by automations on Self_Assessments.
If this disappeared: The intra-Thrivelab provider-to-provider referral handoff with follow-up auditing.
STI_ICD10_Codes · no Deluge code
A focused sub-list of ICD-10 codes specifically for sexually transmitted infection diagnoses, used by the STI-testing arm of VPC. Kept as a separate small reference so STI-related panels (HIV, syphilis, chlamydia, etc.) can pull from a clean shortlist instead of the full ICD master.
Referenced by STI lab type (Lab_Req_info.Type = STI) and VPC STI test selections; no module-level lookups.
If this disappeared: A clean, smaller diagnosis vocabulary for the STI testing service line.
Surgical_Procedure · no Deluge code
The patient's surgical-history record - past procedures with year, free-text name, and notes. Captured during intake and editable thereafter as part of the medical history Thrivelab providers reference before prescribing or recommending therapies.
IN: created during intake.
If this disappeared: A static surgical-history ledger that informs clinical decisions but does not drive automation itself.
Vaccine_Order · no Deluge code
A comprehensive vaccine and well-child / adult-preventive-screening order. Captures age-band-specific recommendations (Birth, 2 mo, 4 mo, 12-15 mo, 11-12 yr, 19-26 yr, 50+, 65+, etc.), travel vaccines, screening tests, and disease-specific monitoring schedules (Diabetes, Hyperlipidemia, Hypertension).
IN: created within an Encounter.
If this disappeared: The single record provider use to issue vaccine orders and preventive-care recommendations aligned to CDC age schedules.
This domain captures Thrivelab's compounding-and-telemedicine medication lifecycle: how the clinical team translates a recommendation into a doctor-signed Prescription, how those orders flow either into internal compounding queues (Medication_Order_Test) or out to external pharmacy partners (External_RXs + External_Med_RX), how dosing and frequency are normalized as reusable building blocks (Dosage_Information, RX_Sig), and how supplement protocols (Supplements_Test) get turned into recurring shipments (Supplement_Order). Surrounding modules govern the partner network (Pharmacy, States_Pharmacy, Products_X_Pharmacy), pricing (Products, Price_Books), telemedicine compliance gates (PDMP_PMP_checks, Prior_Authorization_Forms), patient-facing history (Patient_Medications, External_RXs_History), assessment input to dosing decisions (RSA), and remediation when shipments go wrong (Replacements). Five junction modules stitch the many-to-many relationships together.
Purpose. The actual supplement purchase order placed with a vendor (Xymogen, Vitaboom, Optimal, etc.) - tracks invoicing, shipping, recurring billing, approval, tracking number, and order status. Generated by Rule Engine, user action, Shopping Cart, Plan Approval, or Shopping Cart Peptide.
Connections. IN: Contact -> Contacts, Plan -> Sales_Orders, Encounter -> Encounters, Shopping_Cart -> Shopping_Cart, Supplement_Vendor -> Vendors. OUT (related lists): Standalone_Supplements -> Supplements_Test (line items), Past Orders -> Supplement_Order_Logs, Supplements_x_Encounters junction.
Automation. Submit Supplement Order , Add_Shipping_Item_On_Creation (create), Check_Order_status (date/datetime), Create Next Invoice (date/datetime), Charge Notification (date/datetime), Send Tracking Number SMS , Supplement Purchase Order , Set Next Order Date , Update Next Inv Date , Peptide Order - Provider Approval Task (create), Create Task for PCA - One Off Peptide Order (date/datetime).
Business role. The transactional supplement fulfillment record - invoicing, vendor purchase order, shipment tracking, and recurring re-order scheduling.
Purpose. The per-patient compounded medication order (UI label: "Active Medications") - this is the actual line item that gets compounded by the partner pharmacy and shipped to the patient. Drives DEA checks, add-on toggles (Topi-Click, Veggie Caps, Hypoallergenic Base, Topi Perl), and rolls up into Patient Plan totals.
Connections. IN: Patient -> Contacts, Patient_Plan -> Sales_Orders, Medication -> Products, Custom_Sig -> Dosage_Information, Dose_Frequency -> RX_Sig, ICD10_Code -> ICD_10_Codes. OUT: Active_Me_X_Dosage_In junction (links to Dosage_Information). Referenced by RX_Sig as Active Medication related list.
Automation. Active rules: Create_Order (date/datetime), Calculate Total - Patient Plan (create_or_edit; recalculates plan total, renames record on clientscript failure), Calculate Total - Deleted Med (delete), Add_ons, Add On - Topi Click, Add On - Veggie Caps, Add On - Hypoallergenic Base, Add On - Topi Perl (all field_update), Rename Workflow - Bulk, Recalculate Kits, Check Auto Increase Applicability , Check DEA Status - Created and Check DEA Status - Deleted, review_sg_lv4_price.
Business role. The transactional medication order record that the compounding pharmacy fulfills and that drives the patient's monthly plan price.
Purpose. Prescriptions sent OUT to external pharmacies (i.e., not compounded internally). One record represents a signed RX order routed to a specific partner pharmacy for a patient, with invoicing/reminders for refills.
Connections. IN: Patient -> Contacts, Pharmacy -> Pharmacy, Patient_Plan -> Sales_Orders. OUT: related lists External_Medication -> External_Med_RX (the line items), Treat History -> Treat_Events. Children: External_RXs_History records.
Automation. External RX Reminder Task - 1 day Before, External RX Reminder SMS - 2 days Before, External RX Reminder Task - Calculate Next Date (all date/datetime-triggered refill reminders), Aux Workflow , Send SMS to Patient .
Business role. The outbound prescription envelope sent to an external pharmacy, tracking signing, invoicing, and refill reminders for the patient.
Purpose. Per-patient supplement protocol line items (UI label: "Supplements") - the recommended supplement regimen attached to a Patient Plan or generated from an AI recommendation. Distinct from Supplement_Order: this is the protocol/prescription, the order module is the actual purchase fulfilment.
Connections. IN: Product -> Products, Patient_Plan -> Sales_Orders, Order_Supplements -> Supplement_Order, Custom_Sig -> Dosage_Information, Dose_Frequency -> RX_Sig, AI_rule -> AI_Output. OUT: related list usage from Dosage_Information (Standalone Supplements), Products (Supplements), SupplementsxProducts junction.
Automation. Supplements - Order Total on Creation (create), Supplements - Order Total on Edit , Supplements - Order Total on Delete (delete), Supplements - Add Information on Creation (create). The order-total triad keeps the parent Supplement_Order / plan totals in sync as line items change.
Business role. Defines the supplement protocol (which products, what dose, what frequency, recurring or one-off) attached to a patient's plan.
Purpose. Master product/SKU catalog spanning BHRT compounded medications, peptides, supplements, services, and bundles. Powers pricing, inventory, the patient-facing shop, multi-pharmacy availability flags, supplement protocols, and the relationships needed for both internal compounding orders and external prescribing.
Connections. IN: Vendor_Name -> Vendors, Base_med/Med_Equivalent -> Products, Shop_Store_Front_Content -> Portal_Content_Manager, Initial_Sig -> Dosage_Information, Membership_Option -> Membership_Options. OUT (related lists): Price_Books, Medication_Order_Test, Products_X_Pharmacy, Supplements_Test (both as standalone supplements and via SupplementsxProducts junction), Shop_Cart_Item, External_Medication, Vendors (Vendor Shipping), Cases/Solutions/Contacts/Leads/Deals/Accounts.
Automation. New_Product_Added (create), Sync to Ext Products (edit) - the latter mirrors product changes into External_Medication so the e-prescribing catalog stays current.
Business role. The central product master that every prescription, shop purchase, supplement order, and pharmacy availability flag references.
Purpose. The structured dose-and-frequency record - the granular per-medication dosing instructions that include dose amount, frequency, route/application area, injectable type, and irregularity flags. Acts as the reusable "custom sig" template attached to medication orders.
Connections. IN: Equivalent_dosage -> Dosage_Information (self), Frequency_Lookup -> RX_Sig. OUT (related lists): Medication_Order_Test.Custom_Sig, External_Med_RX.Custom_Sig, Supplements_Test.Custom_Sig, Products.Initial_Sig, plus AI_Output and Active_Me_X_Dosage_In junction. Standalone Supplements related list -> Supplements_Test.
Automation. Review Custom Sig Task (create) - creates a task for PC Plan to review every newly-created custom sig.
Business role. The canonical dosing-instruction record reused by medication, supplement, and external-RX orders.
Purpose. Catalog of medications available through external pharmacies (UI label: "External Products") - the NDC-tagged drug records pulled in from Treat (the e-prescribing partner) for use on outbound RXs. Distinct from the internal Products module: these are the dispensable external SKUs.
Connections. IN: Product -> Products. OUT: related list Medication_RX_Order -> External_Med_RX (the line items prescribed from this med).
Automation. Get Treat Data (create), Refresh Treat Data , Get Data From Products Module . Together they sync the external med record from the Treat API and from the internal Products catalog.
Business role. Reference catalog of externally-dispensable medications kept in sync with the Treat e-prescribing platform.
Purpose. The line-item child of an External RX order (UI label: "External Medications") - one row per drug being prescribed on a given external RX, carrying the actual sig, dose, refills, and dispense quantity. Sits between External_RXs (the envelope) and External_Medication (the drug catalog).
Connections. IN: Contact -> Contacts, External_RX_Order -> External_RXs, Medication -> External_Medication, Custom_Sig -> Dosage_Information, Dose_Frequency1 -> RX_Sig. OUT: surfaced on related lists in RX_Sig (External RX) and External_RXs (External Medication).
Automation. Set Next RX Reminder , Bulk Update .
Business role. The per-drug line item on an outbound prescription routed to an external pharmacy partner.
Purpose. Re-shipment tracking for lost, defective, or empty medication packages - documents the original PO being replaced, the replacement PO, the items, the carrier and tracking number, and the shipment preference (2-day vs Overnight).
Connections. IN: PO_Form -> PO, Contact -> Contacts, Pharmacy -> Pharmacy. OUT: Cadences.
Automation. Update Replacement Item , Notify Replacement Owner - sends a notification to the replacement owner when the tracking number is updated.
Business role. Tracks each lost/defective/empty package remediation through to the replacement shipment.
External_RXs_History · no Deluge code
Historical / audit log of External RX records - one row per snapshot of an external prescription, used to preserve the trail when the parent External_RXs record is re-signed or updated. Holds the Treat link reference.
IN: External_RXs -> External_RXs.
If this disappeared: Append-only history trail of each external prescription's prior states for audit and link preservation.
Junction Modules
PDMP_PMP_checks · no Deluge code
Records of state Prescription Drug Monitoring Program lookups performed before prescribing controlled substances. Each row documents that a provider checked a given state's PDMP/PMP database for a specific patient on a specific date - a compliance artifact required by many states.
IN: Contact -> Contacts.
If this disappeared: Compliance log proving the prescriber consulted the state controlled-substance database before issuing a controlled RX.
Patient_Medications · no Deluge code
The patient's current medication list - a simple per-contact roster of meds the patient is taking, including externally-prescribed ones disclosed during intake. Differs from Medication_Order_Test (compounding orders) and External_RXs (outbound scripts): this is the consolidated "what is on this patient's regimen right now".
IN: Contact -> Contacts, Patient_Plan -> Sales_Orders, Intake -> Intake_Form, Stem_Cell_Intake_Form -> Stem_Cell_Intake_form.
If this disappeared: Maintains each contact's active/inactive medication history captured at intake and from prior care, separate from the practice's own RX issuance.
Pharmacy · no Deluge code
Master record for partner pharmacies (Belmar, Empower, Promise, SandsRx, Lake Hills, etc.) - the entities Thrivelab routes prescriptions to. Stores contact info, fax, Treat IDs, product-type capabilities, shipping rates, and per-pharmacy availability flags consumed by routing logic.
IN: Location_State -> States.
If this disappeared: The partner-pharmacy master record that drives where each prescription can legally and operationally be routed.
Prescription · no Deluge code
Catalog of doctor-signed prescription templates / line items that link a treatment recommendation to a specific drug, form, strength, and price. It is the doctor-side definition of what is being prescribed (as opposed to Medication_Order_Test, which is the per-patient instantiation).
IN: Recommendation_Name -> Recommendation.
If this disappeared: Defines the doctor-authored prescription line items that recommendations and patient plans draw from.
Price_Books · no Deluge code
Per-pharmacy product pricing books. Each record represents a price list (Flat or Differential) for a partner pharmacy and exposes a Products related list for the SKU-level pricing.
IN: Pharmacy -> Pharmacy.
If this disappeared: Stores the contractual pricing tier for each partner pharmacy, used to derive product cost in plan calculations.
Prior_Authorization_Forms · no Deluge code
Insurance prior-authorization paperwork records - one record per PA submission, capturing the diagnosis codes, CPT, place of service, dates of service, group/policy IDs, and the encounter it backs.
IN: Patient_Name -> Contacts, Encounter -> Encounters.
If this disappeared: Captures the pre-authorization submission to insurers tying a specific encounter, diagnosis, and CPT to a patient's policy.
RSA · no Deluge code
"RSA" here is the Routine / Re-Assessment / Self-Assessment data record - a per-patient subform-driven snapshot of symptoms and lifestyle inputs used to inform dosage decisions. Each RSA can chain to a Previous_RSA and back to a SelfAssessment source, giving providers a longitudinal view of how the patient is responding before adjusting medications.
IN: Patient -> Contacts, SelfAssessment -> Self_Assesments, Previous_RSA -> RSA.
If this disappeared: Captures the periodic symptom-and-lifestyle re-assessment that drives dose adjustments and provider review tasks.
RX_Sig · no Deluge code
A reusable prescription instructions (Sig) snippet - the prescriber-shorthand "frequency" that gets applied to a medication order. Stores the abbreviated sig and a numeric multiplier used to scale dispense quantities.
OUT (used as lookup target by): Dosage_Information.Frequency_Lookup, Medication_Order_Test.Dose_Frequency, Supplements_Test.Dose_Frequency1, External_Med_RX.Dose_Frequency1.
If this disappeared: Provides the standardized frequency/Sig codes (QD, BID, Q12H, etc.) reused across every prescription, supplement, and external RX.
States_Pharmacy · no Deluge code
Older / legacy state-to-pharmacy mapping module that records which servicing states a pharmacy operates in. Functionally overlaps with the newer States_X_Pharmacy junction; this one is reached from Pharmacy via the "Services - States" related list.
IN: States -> States, Pharmacy -> Pharmacy.
If this disappeared: Maps each partner pharmacy to the US states it is licensed to ship into - critical for telemedicine routing compliance.
Supplement_Order_Logs · no Deluge code
Append-only log of supplement order events / vendor payloads - one row per submitted order or invoice action, capturing the raw payload and item details for audit and debugging.
IN: Supplement_Order -> Supplement_Order.
If this disappeared: Audit trail of each supplement order submission with the raw vendor payload preserved for troubleshooting.
Thrivelab is a predominantly cash-pay practice — peptides, stem cell therapy, hormone replacement, weight-loss programs, and longevity services are all paid out-of-pocket by patients, typically through saved cards on Authorize.Net/Books-linked payment profiles, monthly subscriptions, or financed installment plans. Insurance only touches a narrow slice of the operation: select labs and primary-care office visits MAY be billed to a payor, which is why the CRM carries a full claims/EOB infrastructure (Claims, Claim_Information, Payors, Contracts, Major_Payor_Contracts, Insurance, Insurance_Requests, Insurance_Refunds, Insurance_Credentialing) alongside the much larger cash-pay machinery (CustomModule5001 Invoices = Books-integrated patient bills, Suscription_Payments, Payment_Methods, Payments_Authorization, Refund_Discount_Requests, Early_Refill_Requests). The two stacks are largely parallel — claims rarely touch the Books invoice that the patient actually paid — and most automation in this domain runs the cash-pay side: card retries, subscription posting, refund/discount approval queues, and early-refill workflows. The vanilla Zoho "Invoices" module is essentially dormant; CustomModule5001 ("Invoices") is the real billing object.
Purpose. Insurance claim package submitted to a payor for a single encounter — carries ICD codes, CPT line items (in the CPT_INFO subform), rendering/billing/service-facility provider info, EOB tracking, and the full denial/appeal lifecycle. Roughly one Claim record per billable encounter, with status polled against the clearinghouse (Stedi-style) for both claim status and 835 ERA payment posting.
Connections. IN from Encounters (one encounter -> one claim), Insurance (patient's coverage), Contracts (payor contract for the service facility), Refund_Discount_Requests. OUT to Claim_Status_History (related list), feeds Refund_Discount_Requests when an overpayment is detected and creates a downstream Books invoice via Invoice_Link/Invoice_ID.
Automation. 16 active rules — calculate_total_charges_from_CPT, calculate_claim_balance_due, compare_allowed_and_billed_amount, Call Patient Responsibility API, Update Balance Due, Update Inv Status, paid_amount_verified, claim_icds_selected, Update_Service_Facility_Address, add_service_facility_address , check_claim_status (scheduled clearinghouse poll), check_claim_835era (scheduled ERA poll), search_claim_encounter_invoice , get_and_attach_claim_pdf + get_and_attach_claim_pdf_resubmitted, refund_approved.
Business role. The insurance-billable claim ledger — only used for the slice of services (labs, some clinic visits) that aren't strictly cash-pay.
Purpose. The patient's coverage record — one per Primary/Secondary/Inactive policy attached to a Contact. Stores plan info, eligibility verification state, prior-auth status, in/out-of-network determination, deductible/copay snapshot, and the patient-facing email cadence around expired or unverified coverage.
Connections. IN from Contacts, Intake_Form, Insurance_Requests. OUT to Claims (claim submission), Verified_Services, prior Insurance records (chain).
Automation. 14 active rules — Update Primary - Create / Update Primary - Edit (Primary policy promotion), Referral_not_needed, EV Emails-Issues-deprecated, EV Emails-Completed, Insurance Info Status-EV/Expired Email 1, Insurance Info Status-UV Email 2, Insurance Info Status-UV Email 3 , Insurance Info Status-EXP Email 2/EXP Email 3 , New Insurance Added - Task AIMA, Temp_send_EV_Email , Close missing insurnace task, review_patient_plan_payment_type.
Business role. The verified-coverage record that determines whether labs/visits can be billed to insurance and what the patient's in-network responsibility looks like.
Purpose. Change-request/correction queue for insurance records — patient or staff submits a new coverage or a correction (Member ID typo, group change, type change). Holds both the existing-record fields and the requested ("RQ_*") values side-by-side so a reviewer can approve, reject, or ask for more info.
Connections. IN from Insurance and Intake_Form. OUT: Insurance record back-references its Last_Insurance_Request.
Automation. 1 active rule — insurance_request_task (creates a task for the AIMA/verification team on submission).
Business role. The audit-trailed approval queue for any change to a patient's insurance record.
Purpose. Workflow for when a patient runs out of medication before their next scheduled refill ships. Captures reason (lost/stolen, travel, dose adjustment, spillage, pharmacy issue), routes to the provider for clinical decision, then to the pharmacy for fulfillment decision, with preventive-measures tagging to spot patterns.
Connections. IN from Contacts (Patient) and Sales_Orders (Patient_Plan). OUT: provider/PCA task creation, eventual PO if approved.
Automation. 4 active rules — Set Status as Pending , Create Task For Provider (on create — routes to clinical reviewer), Add Early Refill Requests Notes to Contacts (on create — annotates the patient record), Create Task For PCA (on field_update — routes to Patient Care Advocate when provider has responded).
Business role. The clinical-plus-fulfillment routing record that decides whether a between-cycle refill gets approved and shipped.
Claim_Information · no Deluge code
A flatter, charge-level breakdown of claim activity sourced from the external clearinghouse/biller — line-item view that complements the Claims module's package view. Each record represents one charge/line with its own status, CPT, control numbers across primary/secondary/tertiary payers, and last-payment timestamps.
IN from Encounters and Contacts (patient).
If this disappeared: The biller's-eye line-item ledger of every claim charge, used for AR follow-up and crossover/secondary-payer tracking.
Contracts (Payors Contracts)
Per-state, per-clinic, per-provider payor contract execution records — children of Major_Payor_Contracts that capture the actual contracted instance, default-contract flag, LOI sent date, and full status lifecycle. Claims reference this module to determine the correct billing service-facility/contract source.
IN from Payors, Major_Payor_Contracts, Books_Agents, Clinic_Addresses, States.
If this disappeared: The execution-level payor contract that actually controls whether a given encounter at a given clinic for a given provider can be billed in-network.
Estimates (CustomModule5002)
Books-synced quote/estimate sent to a patient before they accept a plan. Tracks acceptance/decline, expiry, price changes proposed during plan revisions, and the eventual conversion to an invoice.
IN from Contacts, Accounts, Deals; cross-referenced from Patient Plans (Sales_Orders) and Desk tickets.
If this disappeared: The pre-purchase quote a patient sees and accepts/declines before being invoiced.
Insurance_Credentialing · no Deluge code
Tracks each provider's credentialing data the practice maintains for payor enrollment — NPI, CAQH ID, Medicare PTAN, training/education history, malpractice and criminal-background attestations, OIG/SAM exclusion screening, and sanctions-list screening.
IN from States.
If this disappeared: The practice's regulatory dossier for each provider, the prerequisite for any payor contract application.
Insurance_Refunds · no Deluge code
Tracks refund payouts owed because of insurance activity (e.g. an overpayment surfaced via EOB or a Claims-driven outcome of "Refund Overcharge"). Refunds can either credit the next invoice or push back to the card on file; status follows credit-note creation in Books.
IN from Contacts; tied logically to Claims via the Outcome workflow ("Refund Overcharge").
If this disappeared: The insurance-side overpayment refund ledger, kept separate from cash-pay refunds.
Insurance_form · no Deluge code
Pharmacy-side insurance/prescription dispensing form capturing dispenser, prescriber, and Rx detail (NABP, dosage form, strength, days supply, price, prescription number). Effectively a structured intake of the pharmacy label data tied back to a Patient Plan.
IN from Sales_Orders (Patient_Plan).
If this disappeared: Dispensing-side documentation captured per fill, distinct from the patient's coverage record despite the similar name.
Invoices · 1 function(s), 0 active
Native Zoho CRM Invoices module — effectively dormant in this org. The real patient-facing invoice object is CustomModule5001 (renamed "Invoices") that integrates with Zoho Books; this vanilla module is largely a stub kept around for Sales_Order linkage.
IN from Sales_Orders, Accounts, Contacts.
If this disappeared: Legacy/standard CRM invoice object — superseded by CustomModule5001 for actual billing.
Invoices (CustomModule5001)
The operational patient invoice — synced bidirectionally with Zoho Books and the patient portal. Drives card charges, subscription billing, lab fees, supplements, and consultation fees. Tracks payment lifecycle, retry attempts, written-off balances, and per-Books-org reconciliation.
IN from Contacts, Accounts, Deals, Sales_Orders (Patient Plans), Shipment_Requests, and Wallet.
If this disappeared: The single source of truth for what each patient owes and what's been collected via cash-pay — the dominant billing object at Thrivelab.
Major_Payor_Contracts · no Deluge code
The master/group-level contracting record per payor — represents the overarching contract application (group app or individual) the practice has with a payor, with submission/effective/rejection/resubmission/withdrawal/termination dates and an aggregated provider/state/clinic scope.
IN from Payors, Books_Agents (Provider), Clinic_Addresses, States.
If this disappeared: The strategic, group-level credentialing-and-contracting record per payor — parent to the per-state/per-clinic Contracts.
Payment_Methods · no Deluge code
Saved payment instruments per patient — typically credit cards tokenized through Authorize.Net and mirrored into Zoho Books across the two Books orgs the practice uses (Thrivelab/"TL" and JLMD). One Contact can have multiple cards; the active patient plan picks one.
IN from Contacts.
If this disappeared: The card-on-file vault that makes the cash-pay subscription model possible.
Payments_Authorization · no Deluge code
Pre-charge authorization holds — typically used before an expensive treatment (peptides, BHRT, WL, supplements, membership) so the card is verified for the full amount before the service is rendered. Records the auth ID returned by the gateway and whether the auth was later captured/completed.
IN from Contacts.
If this disappeared: The "card on hold" record that protects the practice on high-ticket cash-pay services before fulfillment.
Payors · no Deluge code
Master list of insurance carriers (Aetna, BCBS, Cigna, UHC, Medicare, etc.) with the integration-level metadata needed to verify eligibility and submit/check claims through the clearinghouse (Stedi).
OUT to Contracts (Contracts.Payor), Major_Payor_Contracts (Major_Payor_Contracts.Payor); related-list "Selected Payor" surfaces on Contacts and "Payor1" on Leads (lead-side payor capture).
If this disappeared: The carrier catalog and clearinghouse-routing table.
Purchase Orders (CustomModule5003)
Pharmacy-facing purchase order for compounded peptides, weight-loss meds, BHRT, and related Rx fulfillment. Carries the script details, prescriber NPI/DEA, courier/tracking, pharmacy status, replacement-PO chain, and overnight/military-ID handling.
IN from Vendors (pharmacy).
If this disappeared: The fulfillment record that gets a patient's compounded medication ordered, signed off, shipped, and tracked from pharmacy to door.
Refund_Discount_Requests · no Deluge code
Approval queue for any refund or discount touching cash-pay invoices — captures which invoice(s) to refund, the categorized reason, amount, target Books org, and credit-note status. Requires manager review and links downstream to Claims (when an insurance-driven refund is involved) and to Books for credit-note issuance.
IN from Contacts.
If this disappeared: The single approval queue that gates every refund or discount, regardless of whether the original payment was cash-pay or insurance.
Sales Orders (CustomModule5004)
"Patient Plan" record — the master subscription/program enrollment a patient signs up for (e.g. a 6-month peptide stack, weight-loss program, longevity package). Drives recurring invoicing, supply tracking, and downstream POs.
IN from Contacts, Accounts, Deals.
If this disappeared: The patient's signed treatment plan — the parent object that organizes recurring invoices, pharmacy POs, and provider approvals over the lifetime of their program.
Suscription_Payments (sic)
Posting record for every recurring/installment charge captured against a patient's subscription or program enrollment. Logs the actual Books invoice paid, the amount, the trainer revenue attribution (for weight-loss/training programs), and ties back to the Enrolled_Service that triggered the recurring charge.
IN from Contacts, Enrolled_Services, Trainers.
If this disappeared: The transaction-by-transaction record of every successful recurring/installment payment — the cash-pay revenue ledger.
This domain is the back-office shipping and procurement engine that keeps prescribed medications, supplements, and ancillary supplies moving between Thrivelab, its pharmacy/supplier vendors, and the patient. The flow has two directions: outbound patient shipments (driven by PO, Fulfillment_Requests, Fulfillment_Queue, Shipment_Requests, and Orders_Processed) and inbound procurement from suppliers (driven by Vendors and Purchase_Orders). A Retry_Module provides a resilience layer for automation failures (charge declines, OCW bookings/invoices, patient sync), and the bundled ZohoSign modules give every approval/RX-signing step a notarized audit trail. Together these modules transform a clinical decision (a signed RX or an approved request) into a tracked package on a patient's doorstep, plus replenishment of the supplies needed to keep doing it.
Purpose. The outbound patient shipment record (a.k.a. "PO Form") - one row per package leaving a pharmacy/vendor en route to a patient. It carries the carrier, tracking number, ETAs, and delivery confirmation, and is the canonical object the system uses to drive SMS notifications, refill counters, and replacement workflows. Despite the name, this is NOT a procurement PO; it is the medication shipment ledger for patients.
Connections. IN: created from Zoho Form submissions by pharmacy/ops staff or from Desk ticket flow (Source); upstream events come from Fulfillment_Queue/Fulfillment_Requests. OUT: Contact -> Contacts; Plan -> Sales_Orders; Stem_Cell_Plan -> Longevity_Installments; related list Replacements -> Replacements module. Drives shipment status back to the parent Sales_Order and updates refill counts on Medication_Order_Test.
Automation. Very active - this is the most automated module in the domain. Active rules: TrackingV2 - Initial Sync (create) and TrackingV2 - Sync to PO (field-update) to pull carrier tracking; TrackingV2 - Scheduled Updates and ...on ETA for ongoing polling; TrackingV2 - Send Tracking Number 8 AM / 8 PM / 8 AM 1 day after scheduled SMS sends; TrackingV2-Delivered/Delayed SMS notifications; TrackingV2 - Populate Delivered Date; Tracking V2 - Reduce Refills and move next invoice (decrements refill counter on delivery and shifts next invoice date); Sync to Patient Plan and PO - On create / On Edit; Tracking Confirmed - Close Desk Ticket; Update Replacement; Belmar - Send Tracking Number; SG Oral Instructions Email.
Business role. The single source of truth for "where is the patient's medication right now" and the trigger for every shipping-related SMS, refill decrement, and replacement.
Purpose. This is the inbound trigger module - a request raised (by clinical staff, support, or the patient flow) asking that something be done for a patient's medication plan: sign an RX, re-sign a plan, issue a one-off, send a 60/90-day script, request an external pharmacy RX, etc. Each request carries a justification, priority (911 Same Day / Critical / Major), and a status that drives downstream RX signing and shipment activity. It is the "ticket" that opens the fulfillment chain.
Connections. IN: created by clinical staff, support, the patient portal/Desk, or upstream RX-related automations. OUT: Patient_Plan -> Sales_Orders; Contact -> Contacts. Approvals here are the upstream event that drives RX signing (zohosign__ZohoSign_Documents), shipment generation (PO), and ultimately Orders_Processed.
Automation. Many active rules: FR_Approved, FR_Rejected, and Belmar-specific variants (FR-Approved_BELMARSG, FR-Rejected_BELMARSG, FR-Approved_one-off) on field-update; FR_Escalate_L1 and FR_Escalate_L2 on date/time SLA; Notify Owner and Add Task and Add Fulfillment Requests Notes to Contacts on create; PDMP Task API (controlled-substance check) on create; FR Auto Close Tasks and Update Task Due Date on field-update; Weightloss autoincrease task when not aproved SLA timer.
Business role. The intake ticket that authorizes any change to what gets shipped to a patient.
Purpose. Patient-initiated shipment modifications against an existing recurring medication plan - skip an upcoming item, delay the next shipment, etc. - submitted by the patient (typically from the portal/Desk) and reviewed by ops. It does not create new prescriptions; it pauses or trims a scheduled shipment.
Connections. IN: created from patient portal / Desk ticket flow. OUT: Patient_Plan -> Sales_Orders; Contact -> Contacts; bidirectional sync with a Desk ticket. When approved, downstream automations adjust the recurring invoice date / line items on the Sales_Order so the next PO is generated correctly.
Automation. Active: New SR (create - assignment & acknowledgement), Escalation (date/time SLA), Sync notes to contact (create), Auto-Close Task (field-update on resolution).
Business role. The patient's self-service lever for pausing or trimming their next shipment.
Purpose. A workflow retry queue for resilience - when an outbound API call or downstream automation fails (record-a-payment, OCW booking, OCW invoice, Treat patient sync), a record is dropped here with the payload, endpoint, attempt counter, and next-action plan so the system can re-attempt instead of silently dropping the operation.
Connections. IN: created by failing automations across the CRM (notably from Sales_Orders payment flows, OCW scheduler integration, and the Treat EHR sync). OUT: feeds a related Retry_Status log; targets external HTTP endpoints. No direct CRM-record lookups - this is plumbing.
Automation. Active create-trigger rules, one per failure class: Retry API - OCW, Retry API - Record Payment, Retry API - OCW Invoice, Retry - Update Patient Data Treat. Each fires the corresponding re-invocation against the saved payload.
Business role. The system's dead-letter queue and self-healing retry engine for integration failures.
Fulfillment_Queue · no Deluge code
The work-in-progress list of medication line items that are ready to be fulfilled. Where Fulfillment_Requests is the inbound ticket and PO is the outbound shipment, Fulfillment_Queue is the staging board operators pull from to assemble the next batch of patient shipments. It's intentionally lean - one row per medication tied to a patient plan, plus an entered-on date.
IN: populated from approved Fulfillment_Requests / Sales_Orders medication line items.
If this disappeared: The operator-facing "what ships next" worklist between an approved request and a created shipment.
Orders_Processed · no Deluge code
The completed shipment log - one record per processed batch of medications for a patient plan, capturing what was actually sent (via a Meds_Proccessed subform) and the tracking number. It is the closed/archived counterpart to Fulfillment_Queue and a flat history table that lets ops answer "what shipped on this plan, when."
IN: written when a PO ships / a fulfillment batch closes.
If this disappeared: The append-only ledger of fulfilled medication batches per patient plan.
Purchase_Orders · no Deluge code
Zoho CRM's standard purchase order module, used here for inbound procurement - buying medications, supplements, lab supplies, or office goods from vendors. Distinct from PO (which is patient-outbound), Purchase_Orders has a Vendor, billing/shipping addresses, line items, taxes, totals, and status (Created / Approved / Delivered / Cancelled).
If this disappeared: Standard supplier-side accounts-payable purchase order, used to buy stock from vendors.
Vendors · no Deluge code
The supplier/pharmacy entity master - companies Thrivelab buys from or routes patient shipments through (compounding pharmacies like Belmar, supplement suppliers, etc.). It carries contact info, GL account mapping, currency, and a default product (Standard_Shipping) used when generating shipments through this vendor.
IN: created/maintained by operations.
If this disappeared: The supplier/pharmacy directory that all procurement and shipping flows reference.
ZohoSign Integration
zohosign__ZohoSign_Documents, zohosign__ZohoSign_Recipients, and zohosign__ZohoSign_Document_Events are Zoho's bundled e-signature integration modules. They are event-sourced from the ZohoSign service - records are created and updated automatically by the ZohoSign-CRM connector whenever a document is sent, viewed, signed, declined, or completed; the CRM does not author them directly. Within the Thrivelab fulfillment domain they back RX signing, plan resigns, one-offs, vendor contracts (related list on Purchase_Orders), and any patient/provider consent flow.
If this disappeared: Notarized audit trail for every signature-required event in the fulfillment chain - RX signings, plan resigns, vendor agreements, and patient consents.
The Communications domain is how Thrivelab actually talks to patients - and how patients talk back. It spans three lanes that look similar from the outside but serve different purposes: (1) the secure HIPAA-compliant chat thread between a patient and their care team (Chats + Patient_Messages, branded internally as "SHM" - Secure Health Messaging), (2) the outbound transactional/marketing surface (SMS_Backup as the Twilio SMS archive, Voicemails as the inbound voicemail log), and (3) the patient-facing portal CMS (Portal_Content_Manager, Portal_Pages, Portal_Groups) that drives what patients see when they log into the Thrivelab app. Two legacy social modules (Facebook, Twitter) and a credential vault (APIS) round out the domain. The Communications module itself is not a message log - it is the template library ("IT Message Templates") that feeds the rest of the system with reusable copy, subject lines, and channel routing rules.
Purpose. The carrier-level SMS message archive - every inbound and outbound SMS the practice sends through Twilio is logged here with full Twilio payloads, SID, status, and error codes. Unlike Patient_Messages (which is in-portal chat), SMS_Backup is the actual cell-network text traffic, used for compliance, retries, status polling, and campaign / journey tracking.
Connections.
- IN: created by buttons across Leads/Contacts/Sales_Orders and by Zoho Flow when sending templated SMS.
- OUT: Lead -> Leads, Contact -> Contacts, Ambassador -> Ambassador_Management.
Automation. Heavily automated (13+ active rules):
- Send_SMS_On_Creation, Send_Message_Button, Send SMS on Schedule - the actual outbound dispatchers.
- Sync 'To' and 'From' and send message, Sent_By_Sync (create) - normalize sender/recipient fields.
- SMS status on create, Check SMS status recurrent, Check_SMS - poll Twilio for delivery status updates.
- Create_Task_When_Message_Received (create) - inbound SMS becomes a task.
- Create_ticket_in_desk_if_ticket_not_found - escalates inbound SMS to Zoho Desk when no matching thread exists.
- Add Note when patient confirms appt - parses confirmation replies.
- NP Survey and Trust Pilot Review - sends post-encounter review request.
- SMS Journeys - drip-style multi-step SMS journeys (e.g. "No Card" recovery).
Business role. The SMS engine and compliance archive - both the outbound sender and the inbound listener for everything Twilio.
Purpose. The HIPAA-compliant Secure Health Messaging (SHM) thread between a patient (Contact) and their assigned provider/PCA. Each Chat record is a conversation container - the individual messages live in the related Patient_Messages module. Chats track who owes the next response, when the thread should auto-close, and how the conversation was routed between Provider Care Associates (PCAs) and licensed providers.
Connections.
- IN: child messages from Patient_Messages (related list), Encounters link back via Chats field.
- OUT: Contact -> Contacts, Agent/Chat_Type related to Books_Agents and Portal_Content_Manager, Encounter -> Encounters, Patient_Plan -> Sales_Orders.
Automation.
- Link Patient Plan to Chat (create) - auto-attaches the active Sales Order.
- Add Chat Notes to Contacts (create) - mirrors notes back to the patient record.
- Scheduled SHM + Send Schedule SHM (create / date_or_datetime) - lets staff queue a message for future delivery.
- Send Autoclose Message - 36 hours after no response and Autoclose SMS - the inactivity timeout that closes stale threads with a friendly SMS.
- Sent Survey on Closed - triggers a patient satisfaction survey when Status flips to Closed.
- mark_as_transferred_to - records PCA<>Provider handoffs.
Business role. The single source of truth for asynchronous, compliant clinical conversation - the SHM inbox every PCA and provider lives in.
Purpose. The individual messages inside a Chat thread - one row per sent or received message. Where Chats is the conversation container, Patient_Messages is the message log itself, including who sent it, when, whether it was read, and whether it was an automated/scheduled message vs a human reply.
Connections.
- IN: created from the Chats module's related list.
- OUT: Chat -> Chats (parent), Contact_Name -> Contacts, Sent_by / Chat_Agent -> Books_Agents.
Automation.
- Sync_Sent_By (create) - normalizes the sender to a Books_Agents record.
- Create_Task_When_Message_Received (create) - generates a follow-up task for the assigned staff member.
- Close_Notification_When_Msg_is_read - dismisses the in-app/portal notification badge.
- send initial automated message - fires the canned welcome/initial message at thread start.
- Calculate Message Duration (create) - computes Duration from Start_Time/End_Time for chat-time tracking.
- Scheduled Message - Sent - releases messages queued via Hide_Message/Sending_Time.
Business role. The atomic message log - distinct from Chats (the thread) and from SMS_Backup (the carrier-level SMS archive); this is the in-portal chat bubble.
Purpose. The credential vault for outbound integrations - every external API the CRM talks to (Twilio, payment processors, EHR/lab vendors, Ayumetrix, etc.) has a row here holding its OAuth client ID/secret, current access token, refresh token, expiry, and any vendor-specific IDs. Sensitive: this module concentrates the practice's third-party secrets.
Connections. No formal lookup relationships - this is read by Zoho Functions / Flows that need to authenticate outbound calls. It is referenced operationally rather than relationally.
Automation.
- Refresh Token - the critical job that hits each integration's OAuth refresh endpoint before Expires, persisting the new Access_Token / Refresh_Token / Issued_At. Without this, every external integration would silently break when tokens expire.
- Demand Gap Updater - a scheduled vendor-data sync of some kind (name suggests inventory/supply gap tracking against an external API).
Business role. The OAuth/secret store - one row per vendor integration, kept alive by an automated token refresher so the rest of the CRM can call out without re-auth.
Communications · no Deluge code
The "IT Message Templates" library - a template store, not a message log. Each record holds the reusable copy, subject line, channel (SMS / Email), and routing metadata for a specific automated communication (meeting reminders, SA-missing prompts, intake-missing prompts, dynamic-program emails, chat templates, etc.). Workflows across the CRM pull from this module by Key rather than hardcoding text.
If this disappeared: The "copy deck" of the practice: every automated patient-facing message is rendered from a row here, so non-developers can edit wording without touching code.
Facebook · no Deluge code
A Zoho-standard social-CRM listening module - one row per Facebook post / comment / message captured by Zoho's Social/CRM integration. Read-only (Creatable / Editable / Deletable all False).
SOCIALID lookup points to a generic social profile (target N/A in metadata, i.e.
If this disappeared: Vestigial - this is Zoho's out-of-the-box social listening capture, not actively wired into Thrivelab's care workflows. Likely unused or minimally referenced; effectively dead weight unless social listening has been re-enabled.
Portal_Content_Manager · no Deluge code
The CMS / content library that powers the patient-facing Thrivelab portal app. Each record is a piece of structured content - a blog post, podcast episode, meditation, store product card, notification, quote-of-the-week, plan presentation slide, treatment exploration card, etc. - tagged by Type so the portal can render it in the right surface.
Chats.Chat_Type and Communications.Content_Portal_Source both lookup here, so a content card can also act as a chat template / message source.If this disappeared: The headless CMS feeding the patient app: blogs, podcasts, meditations, store cards, notifications, and plan-presentation content all live here.
Portal_Groups · no Deluge code
The top-level menu sections / categories that group Portal_Pages together in the patient app navigation (e.g. a "Health", "Wellness", "Store" type of bucket). Small, simple lookup table.
Portal_Pages.Portal_Group looks up here; related list Portal Pages on each Group record.If this disappeared: The portal navigation taxonomy - the menu groupings that organize Portal_Pages.
Portal_Pages · no Deluge code
The route/navigation registry for the patient portal - each row is a named page or screen in the app, with its route path, icon, display order, and which Portal_Group (menu section) it belongs to. Effectively the sitemap of the patient app.
Portal_Groups (related list).If this disappeared: The portal's navigation/access map - which screens exist, in what order, gated by which membership.
Twitter · no Deluge code
Mirror of the Facebook module for Twitter/X - read-only social capture of tweets, comments, and DMs through Zoho's social integration.
Same as Facebook - SOCIALID points nowhere useful inside the tenant, no link to Contacts/Leads.
If this disappeared: Vestigial - same story as Facebook. Standard Zoho scaffolding that ships with every CRM tenant; not part of Thrivelab's operational stack.
Voicemails · no Deluge code
Inbound voicemail records, almost certainly sourced from the Twilio voice integration. Each row captures a single voicemail with caller metadata, duration, and the transcribed detail so staff can triage and route without listening to audio.
No formal lookup relationships - linkage to a patient is done loosely through Who_What_ID and Call_From.
If this disappeared: A lightweight inbound-voicemail inbox that ensures missed calls turn into tracked work items rather than orphaned audio files.
This domain is the operational connective tissue of the Thrivelab CRM — mostly Zoho-standard activity and support modules (Tasks, Events, Notes, Attachments, Cases) layered with HIPAA-specific audit modules (Access_Log, HR_Logs, Staff_Changes), an in-house support pipeline (Support, Desk_Tickets, Escalations), and reference data tables (States, Countries, State_Details) tuned to US healthcare delivery (telemedicine compact rules, pharmacy availability per state, license costs). The defining traits of this domain are (a) heavy customization of Zoho-built-in modules with healthcare- and ops-specific fields, (b) universal "related list" surface area — Tasks/Notes/Attachments attach to nearly every other module — and (c) audit-trail requirements driven by HIPAA and patient-safety compliance.
Purpose. Calendar / appointment module (Zoho's built-in Meetings), deeply customized as the appointment engine for telehealth, virtual primary care, stem cell, regenerative, life coaching, and nutrition visits. Bidirectionally synced with Zoho Bookings and Google Calendar; drives copay billing, no-show fees, reminders, and most patient-journey automations.
Connections. OUT: Who_Id → Contacts; What_Id → polymorphic. IN: target of Tasks, Notes, Attachments, Invitees, Checklists. Integrates with Zoho Bookings, Google Calendar, Twilio (no-show SMS), Woosender (pipeline updates), Zoho Desk.
Automation. ~80 active workflow rules — the busiest module after Tasks. Highlights: full reminder ladder (Meeting_reminder, 1_day_before, 1_hour_before), Master Meeting Outcome Workflow, Charge Appointments - Real Time, Charge FU Appt BHRT - Real Time, No Show - Task and Payment Time + No Show Payment Date, Plan Not Approved after ITH-8H/-48h, ITH No Show Loop, Ghost ITH SMS - Reminder 1/2/3, Staff Booked-Rescheduled-Canceled Notifications, addEventsToZohoBookings, Convert Lead to contact - Special Services, Insurance Referrals - Assign provider and send reminders, Move meeting recordings to drive.
Business role. The appointment system of record — every patient interaction with a provider is an Event.
Purpose. The operational backbone of the CRM — a heavily customized version of Zoho's built-in Tasks module that drives nearly every ops workflow (retention loops, payment-failure escalations, provider escalations, plan audits, PDMP, insurance follow-ups, SMS handling, offboarding). Referenced by ~22 other modules and the destination of dozens of workflow rules across the system.
Connections. IN: every operational module fires tasks (Sales_Orders, Encounters, Insurance, Early_Refill_Requests, External_RXs, Survey, Escalations, Support, Events, Leads, Contacts, etc.). OUT: Who_Id → Contacts; What_Id → polymorphic se_module (any record). Synchronized bidirectionally with Zoho Desk via Desk_Task_id.
Automation. ~45 active workflow rules — among the busiest in the system. Highlights: Priority Increment (Minor → Major → Urgent → Critical daily), full Payment Failure - Day 0/1/2/7/8/9 ladder with SMS/email, Provider Escalation chain with date-based reassignment, Retention Follow Up + Retention Outcome - Auto Close, Sync_Task_With_Desk, 911 Task Email / 911 Support Task Overdue, Plan Audit Overdue, Addendum Overdue Task, Offboarding Meeting Attempt 2/3, Notify Auditor Backup Closed Workflow, Insurance Request Closed Without Insurance, No VOB Task - After NPA.
Business role. The default execution layer of the CRM — anything that needs a human to do something becomes a Task.
Purpose. Patient-facing notification / action queue surfaced in the patient mobile app (the "Notification Center" view is the default). Distinct from Tasks: Actions_Items are open items shown to the patient or member (links to specific app paths like /insurance, /license, /my-medications), each with a Due_Date, optional Loyalty_Points reward, and a Completed date.
Connections. OUT: Contact → Contacts, Content → Portal_Content_Manager, Chat → Chats, Device → Mobile_App_Devices. IN: created by Tasks workflow (Create Action Item Payment Failure), Events (Action Items for Follow Up Appts, Update Available Serv Provider and Services Action Items), and others.
Automation. 6 active rules: Notification Email - SMS On Creation, Notification Email - SMS on Edit, Autoclose Notifications, Add Loyalty Points, send_push_notification (CRM → mobile push), TN Progress Check.
Business role. The patient-app "to-do list" — open / pending items the patient still needs to handle.
Purpose. Internal request / IT ticket queue used by staff (Fulfillment, IT, HR, Payroll, Insurance, Labs, L&D, Marketing, PCC, PCA, Nutritionist, Longevity Provider, etc.) to submit tickets — bugs, feature requests, data requests, one-time ops asks, comms updates. Distinct from Desk_Tickets (which are inbound patient tickets from Zoho Desk) and from Cases (which is the legacy Zoho Cases module).
Connections. OUT: Contacts → Contacts, Leads → Leads, Encounters → Encounters, Patient_Plan → Sales_Orders.
Automation. 3 active rules: Support_Ticket , Create Support Ticket on Creation, Check_Ticket_or_Task_Creation (date-based — decides between spawning a Task vs a Desk Ticket).
Business role. Internal-facing service desk — staff requests routed to the right department.
Access_Log · no Deluge code
Per-user / per-record access audit trail for HIPAA — captures which staff user (User) accessed which patient (Contact) at what timestamp (Date_Time_1). Required infrastructure for any healthcare CRM handling PHI.
OUT: Contact → Contacts, User → CRM Users.
If this disappeared: HIPAA access-audit table — who saw which patient's chart and when.
Actions_Performed · no Deluge code
Read-only event log of actions taken by visitors / patients on tracked surfaces (Zoho's PageSense-style visit telemetry). Records every Action_Type, the page visited, and time spent. Configured as non-creatable / non-editable / non-deletable via the UI — populated only by system writes.
OUT: Parent_Id → Visits (each performed action rolls up under a visitor session), Chat_Attachment → Attachments.
If this disappeared: Visitor-behavior audit trail (completed/historical counterpart to Actions_Items).
Attachments · no Deluge code
Zoho's standard universal attachment module — binary files (PDFs, images, etc.) linked to any parent record via polymorphic Parent_Id. Universal related list across the CRM; not editable post-upload (Editable=False).
Polymorphic IN from every module.
If this disappeared: Universal file storage related-list — any record can carry attached documents.
Cases · no Deluge code
Zoho's built-in Cases module — the legacy/standard case-management object that ships with every Zoho CRM. Largely vestigial here: configured with stock fields (Status, Priority, Type, Case Reason, Case Origin) and very limited customization. The active support and escalation work flows through Support, Desk_Tickets, and Escalations instead.
OUT: Related_To → Contacts, Account_Name → Accounts, Deal_Name → Deals, Product_Name → Products.
If this disappeared: Vestigial Zoho-standard case object — kept for completeness; real case work lives in Support / Desk_Tickets / Escalations.
Countries · no Deluge code
Country reference lookup — minimal schema, kept for international addressing / contact normalization. Practically only used as a dropdown source.
No declared FK lookups out; receives standard related lists.
If this disappeared: Country reference list — minimal infrastructure module.
Desk_Tickets · no Deluge code
Inbound patient support tickets imported from Zoho Desk into the CRM for analytics, redaction, and LLM-based topic labeling. Each record stores the raw conversation, a redacted (PHI-stripped) copy, and an auto-classified topic set.
No declared FK lookups on this module — linked to Contacts indirectly via Contact_ID text field.
If this disappeared: Analytics + voice-of-customer pipeline for Zoho Desk tickets — feeds topic/sentiment reporting on patient support contacts.
Escalations · no Deluge code
Lightweight tracker for issues that need management attention — co-insurance inquiries, prior auth, VOB requests, PCC training escalations, and process questions. Creates a follow-up task on creation; the parent record is the running narrative of who-owns-the-resolution.
OUT: Contact → Contacts.
If this disappeared: Management-attention ticket — anything the front line can't resolve and needs escalated.
HR_Logs · no Deluge code
Free-form HR log entries about a contact or staff member — onboarding notes, performance observations, disciplinary records, training events. Light schema by design: a description plus the patient/contact and the staff user involved.
OUT: Contact → Contacts, Patient_Plan → Sales_Orders, User → CRM Users.
If this disappeared: Internal HR notebook — staff-related events tied to a patient or plan context.
Important_Notes · no Deluge code
Pinned / high-visibility notes scoped specifically to a Contact — distinct from generic Notes because they surface prominently on the patient record and can be flagged for removal. Used for patient-specific must-read flags (allergies, behavioral flags, billing instructions, etc.).
OUT: Contacts → Contacts.
If this disappeared: Patient-record "pinned banner" — must-see info that staff should see every time they open the chart.
Notes · no Deluge code
Zoho's standard universal note module — a single Note_Title + Note_Content attached to a parent record via a polymorphic Parent_Id. Appears as a related list on essentially every other module in the system.
Polymorphic IN from every module.
If this disappeared: Universal free-text annotation layer for any record in the CRM.
Payroll_Events · no Deluge code
Compensation / commission events tied to specific patient actions — currently used to credit staff when a lead books a Nutrition Coaching Intro or Life Coaching Intro meeting (each event carries an amount).
OUT: Contact → Contacts, Lead → Leads.
If this disappeared: Commission/booking-bonus ledger for staff payouts.
Staff_Changes · no Deluge code
Audit log of provider / care-team reassignments for a patient — when a patient's DPC, NP, or Contact Owner changes, a record is written here for traceability.
OUT: Patient → Contacts.
If this disappeared: Care-team provenance log — who-was-the-provider-when, for compliance and continuity-of-care review.
State_Details · no Deluge code
Per-(State × Service) join row that holds service-specific scheduling constraints — most importantly the Minimum_Booking_Notice_Min, which controls how far in advance a given service can be booked in a given state. Pairs with States for "what's available here" data and Bookings_Services for service definitions.
OUT: State → States, Service → Bookings_Services.
If this disappeared: Per-state service configuration — fine-grained scheduling rules per service per state.
States · no Deluge code
US-state reference lookup table customized for healthcare delivery — each state row carries the programs available there (Semaglutide variants, controlled-substance rules, supplements), the licensed pharmacies, compact-state flags for nursing and APRN licensure, license + renewal costs, peptide and supplement vendor availability, and collaboration requirements.
If this disappeared: The state-rules lookup — every "is X allowed in this state?" check resolves against this module.
System & Infrastructure Modules