Default settings

Automatic Organization Matching by Email Domain

Overview Simply CRM includes a default automation that helps you automatically relate Contacts to the correct Organization based on their email domain(s). This ensures that Contacts are connected to the right Organization without manual work. How It Works 1. Email Domain(s) Field on Organizations Each Organization has a field called Email Domain(s). If this field is empty, it will automatically be filled based on the Organization’s Primary Email. It is possible to manually add multiple Email Domains by listing these with "," between "lego.com, legogroup.com" Example: - Primary Email: leo@lego.com - Email Domain(s) (auto-filled): lego.com 2. Automatic Contact–Organization Matching If an Organization has an Email Domain filled in: - Any Contact with an email from that domain (e.g. *@lego.com) - And without an existing Organization relation Will automatically be related to the matching Organization. Example: - Organization Email Domain(s): lego.com - New Contact Email: anna@lego.com - Result: Contact is automatically related to the LEGO Organization When Does This Apply? The auto-relation only happens if: - The Contact does not already have an Organization assigned - The Organization has an Email Domain(s) value - The Contact email domain matches the Organization’s Email Domain(s) How to Disable This Feature You can disable this functionality by turning off one or both workflows: Option 1: Disable Auto-Fill of Email Domain(s) (Organizations) Disable the workflow that automatically fills the Email Domain(s) field based on the Primary Email in the Organizations module. Option 2: Disable Auto-Relation of Contacts Disable the workflow in the Contacts module that automatically relates Contacts to an Organization based on matching Email Domain(s). Recommended Usage This feature is especially useful if: - You work with B2B customers - Most Contacts belong to a company domain - You want to reduce manual linking of Contacts to Organizations If you work in environments where email domains are shared across multiple companies, you may consider disabling the feature. If you are unsure which workflow to disable, please contact your system administrator.

Tenant Subscription Management

Short summary (how it works) Tenant Subscription Management automatically keeps your subscription billing in sync with how many users are actually active on each Tenant. Active Tenant Users are rolled up daily and compared to the subscription on the Sales Order. If more users are active than paid for, the difference is invoiced and the subscription is increased. At renewal, the subscription is adjusted to match the current number of active users. Overview This setup is designed for user-based subscriptions (seat licensing) where customers can add or remove users over time, and billing should reflect real usage without constantly adjusting subscriptions up and down during a billing period. The model separates: - Actual usage (who is active right now) - Subscription baseline (what is currently paid for and will renew) This makes billing predictable while still ensuring that additional usage is billed correctly. Modules involved In addition to standard vtiger modules, the setup uses: - Tenants Represents each customer environment / SaaS tenant. - Tenant Users (TU) Each record represents one licensed user belonging to a Tenant. Typical fields: - Tenant (relation) - Product / License type (relation) - Status (Active / Inactive) - Start date (and optional End date) - Sales Orders (SO) Represents the active subscription. Each product line represents a license type, and the quantity represents the number of paid seats for the current period and future renewals. How the billing logic works Daily seat rollup (scheduled workflow) A scheduled workflow runs once per day and performs the following steps: 1. Roll up active Tenant Users For each Tenant and license type, the system counts how many Tenant Users are currently active. 2. Compare usage with subscription baseline The active user count is compared with the quantities on the related Sales Order. 3. Handle over-usage (scale up) If the number of active users is higher than the number of paid seats: - The difference is invoiced as an adjustment (typically prorated until the next renewal date). - The Sales Order line quantity is increased so the new seat count becomes the new subscription baseline. 4. Handle under-usage (scale down) If the number of active users is lower than the number of paid seats: - No refund is created during the active period. - Freed seats remain available and can be reused by new users. This ensures that: - Additional usage is always billed. - Temporary reductions in users do not constantly change the subscription mid-period. Subscription renewal (period start workflow) At the start of a new billing period (before the recurring invoice is generated): 1. Recalculate the baseline - The Sales Order quantities are updated to match the current number of active Tenant Users. - Quantities can go both up or down at renewal. 2. Recurring invoicing - The normal recurring invoice process uses the updated Sales Order quantities as the basis for the new period’s subscription invoice. This ensures that each new period starts with a subscription that reflects the real current usage. Key principles - Tenant Users = actual usage This is the source of truth for how many licenses are really in use. - Sales Orders = billing baseline This is what customers are currently paying for and what will renew next period. - Scale up during the period, right-size at renewal - During a period: only increases are billed. - At renewal: the subscription is aligned to real usage (up or down). Customization The setup can be adapted to different business rules, for example: - Different TU statuses (e.g. Pending, Suspended). - Different proration models for mid-period upgrades. - Custom pricing or discounts per Tenant or license type. As long as Tenant Users represent real usage and Sales Orders represent the paid baseline, the model remains simple, predictable, and flexible.

Standard Billing Flow

TLDR (Quick Overview) 1. Billing details are defined on the Organisation. 2. These include billing email, billing contact, CC/BCC, and EAN number. 3. When a Sales Order is created, these billing details are automatically copied. 4. The Sales Order also defines how invoices should be sent (email, EAN, or not sent). 5. When an Invoice is created from the Sales Order, the same billing settings are copied. 6. If Email is selected, the invoice is sent to the organisation billing email and billing contact. 7. CC and BCC recipients are included automatically. 8. If EAN is selected, the invoice is sent via EAN and an informational email is sent to the billing recipients. 9. An invoice is only sent if a PDF exists and the invoice is booked/posted. 10. Invoice lifecycle fields track status such as sent date, overdue, and paid date. Standard Billing Setup The standard billing setup ensures that invoice delivery details are defined once on the Organisation and automatically reused on Sales Orders and Invoices. This reduces manual work and ensures invoices are always sent to the correct recipients. 1. Organisation (Billing Setup) Billing information is primarily defined on the Organisation record. Typical fields include: - Billing email (organisation’s main invoicing email) - Billing contact (specific person responsible for invoices) - Billing CC (additional recipients) - Billing BCC (hidden recipients) - EAN number (for electronic invoicing) These fields act as the default billing configuration used throughout the invoicing process. 2. Sales Order When a Sales Order is created and linked to an Organisation, workflows automatically copy the billing details from the Organisation. This typically includes: - Billing contact - Billing CC - Billing BCC - EAN number - Invoice delivery method The Sales Order also contains a dropdown field: How should we send invoice(s) Typical options: - Send per email - Send per EAN - Do not send This setting determines how the invoice will later be delivered. 3. Invoice Creation When an Invoice is created from a Sales Order, the system copies the billing settings from the Sales Order. Copied fields include: - Organisation - Billing contact - Billing email - CC / BCC recipients - EAN number - Invoice delivery method This ensures the invoice inherits the same billing configuration as the order. 4. Sending the Invoice The selected delivery method determines how the invoice is sent. Email If Email is selected: The invoice is sent to: - Organisation billing email - Billing contact email Additional recipients from CC and BCC are included automatically. The email can also include a greeting such as: Hi <contact-firstname> EAN If EAN is selected: - The invoice is sent through the EAN network. - An informational email is also sent to the normal billing recipients. Do Not Send If Do not send is selected, the system will not automatically send the invoice. 5. Conditions for Sending An invoice will only be sent automatically if: - A PDF version of the invoice exists - The invoice status indicates that it has been booked / posted This prevents incomplete invoices from being sent. 6. Invoice Status Tracking Invoices track several lifecycle statuses, such as: - Draft - Approved - Booked - Sent (with date) - Read / received (with date) - Overdue - Partially paid - Paid (with date) These fields make it possible to monitor the full invoicing lifecycle.