customer_type.use_metafield_customer_type | Use metafield customer type | false | — | Use customer_type metafield instead of customer/affiliate |
warehouse.new_missing | Create missing warehouses | false | — | Automatically create warehouses that exist in external system |
product.new_inactive | New products inactive | false | — | Set newly synced products as inactive by default |
product.no_warehouse_inactive | No warehouse = inactive | false | — | Set products without warehouse as inactive |
product.warehouseless_product_handling | Products without a warehouse | mark_inactive | mark_inactive, sync, skip | How to handle a product that has no warehouse. |
product.product_changelog_sync | Product changelog sync | false | — | Enable changelog-based polling for product updates from Exigo. |
country_market.new_missing | Create missing country markets | false | — | Automatically create country markets from external system |
rank.new_missing | Create missing ranks | false | — | Automatically create ranks that exist in external system |
rank.sync_ranks | Sync ranks | true | — | Enable rank synchronization |
rank.pulled_from | Rank pulled from | customer | customer, rank, paidrank | Source for rank data during synchronization |
rank.period_type | Period type | — | — | Period type for rank volume calculation |
ship_method.new_missing | Create missing shipping methods | false | — | Automatically create shipping methods that exist in external system |
customer_metadata.sync_metadata | Sync metadata fields | false | — | Enable synchronization of customer metadata fields |
customer_metadata.overwrite_existing | Overwrite existing metadata values | false | — | Overwrite existing customer metadata values during sync |
order_metadata.sync_metadata | Sync metadata fields | false | — | Enable synchronization of order metadata fields |
order_metadata.overwrite_existing | Overwrite existing metadata values | false | — | Overwrite existing order metadata values during sync |
product_metadata.sync_metadata | Sync metadata fields | false | — | Enable synchronization of product metadata fields |
product_metadata.overwrite_existing | Overwrite existing metadata values | false | — | Overwrite existing product metadata values during sync |
order.refund_handling | Refund orders | hold | hold, sync, skip | How to handle refund and return orders. |
order.duplicate_order_handling | Duplicate orders | skip | skip, sync, hold | How to handle an order that already exists in Fluid. |
order.order_changelog_sync | Order changelog sync | false | — | Enable changelog-based polling for order updates from Exigo. |
order.order_creation_sync | Order creation sync | false | — | Enable polling for new orders created in Exigo. |
order.import_skip_flag_field | Skip-import flag field | None | None, Other1, Other2, Other3, Other4, Other5, Other6, Other7, Other8, Other9, Other10, Other11, Other12, Other13, Other14, Other15, Other16, Other17, Other18, Other19, Other20 | Exigo order Other field that marks an order this platform must not import: when it holds 1 (or true), order creation polling and changelog JIT recovery skip that order, while 0, false and blank import as before. Use it when a second system creates orders in this Exigo database on your behalf (a checkout that creates the Exigo order itself) — Fluid receives its own order for the same purchase moments later, so importing the Exigo row would land a duplicate, permanently unpaid Fluid order. Blank (default) = no check, and the scan is unchanged for every tenant that leaves it blank. |
order.adopt_checkout_order_id | Adopt the checkout-created Exigo order | false | — | When on, an order whose metadata carries exigo_order_id — stamped by a checkout that created the Exigo order itself — adopts that OrderID instead of creating a second Exigo order, and the id is written back to the Fluid order as its external_id so both sides stay linked. Off (default) = the export behaves exactly as before. PREREQUISITE: storing the id also routes every later order update through Exigo UpdateOrder, which overwrites that order with the totals Fluid holds. Leave this off until the cart-pricing fixes land, or those updates will replace a correct Exigo total with a wrong one. |
order.return_order_export | Return order export | false | — | When enabled, Fluid refunds create matching Exigo Return Orders (OrderType=8) for commission tracking. Each refund maps to one Return Order pointing back to the original Exigo OrderID. |
order.return_order_import | Return order import | false | — | Inbound mirror of return order export. When enabled, Exigo Return Orders (OrderType=8) are mirrored into Fluid as refunds pointing at the original order. Each Exigo Return Order maps to one Fluid refund. |
order.fraud_decision_field | Fraud decision field | Other11 | Other1, Other2, Other3, Other4, Other5, Other6, Other7, Other8, Other9, Other10, Other11, Other12, Other13, Other14, Other15, Other16, Other17, Other18, Other19, Other20 | Which Exigo Other field the fraud/review decision value is stamped into. Applies to all fraud decision mappings for this integration. Defaults to Other11. |
order.price_type_role_titles | Price type by customer role | — | rep, preferred, customer, admin | Optional. Maps a Fluid customer role (for instance “rep”) to the price type title used for that order, overriding the price type the order itself carries. The title must be named by a Price Type Mapping row for this integration; one that is not holds the order instead of falling back, so a typo here is visible rather than silent. Leave empty (the default) to use each order’s own price type, which is the behavior for every role that is not listed. With “Resolve customer type from member type” off an order carries the legacy role, so only admin, rep, customer and preferred_customer can match; any other member-type slug needs that setting on — including the seeded subscriber tier, whose slug is “preferred”, NOT the legacy “preferred_customer”. |
order.wallet_merchant_type_id | Wallet payment merchant type | — | — | When set, an e-wallet payment whose Fluid payment method has a Wallet Type mapping is sent to Exigo as a CreatePaymentWalletRequest carrying this MerchantTypeID, so the invoice names the actual tender (e.g. GCash) instead of a generic wallet label. Exigo requires this field, so leaving it unset (the default) disables the behavior and leaves e-wallet payments as generic payments. |
order.export_gross_to_other1 | Export gross product prices to Other1 | false | — | When on, each product line carries its gross VAT-inclusive price in Other1Each, and the order-level discount line carries Other1Each = PriceEach to match. The two move together on purpose so the order Other1 column stays internally consistent. |
order.order_field_mappings | Order field mappings | — | — | Stamp a Fluid order attribute (e.g. Order number) into an Exigo order Other field (Other1-20) on export. Only configured mappings are stamped. |
order.commission_enrichment | Commission enrichment | — | — | Stamp order-line Exigo Other fields from Exigo ItemPrices at a chosen price type. |
order.commission_skip_child | Commission enrichment: price the parent only | false | — | When on, bundle child lines (with a parent item) are left unenriched so the commission stays on the parent line. Off (default) enriches every line. |
order.commission_return_reversal | Commission enrichment: reverse on return orders | false | — | When on, a return order reverses the configured fields using the per-unit values the PARENT order recorded in Exigo, rather than today’s prices. Business volume and commissionable volume can only be reversed this way — they are never stamped on a forward order, where Fluid is the source of record. Off (default) leaves return orders untouched. |
order.commission_discount_scale_basis | Commission enrichment: what a discount scales by | price | price, cv | Which reduction a scale_by_discount entry follows. “Order price discount” (default) spreads one order-wide ratio across every stamped line, so a discount that removed no volume — an insert promo delivered as a one dollar line plus a one dollar discount — still reduces the commission on the real product. “Line commissionable volume” measures each line against its own catalogue volume, so only a discount that actually reduced volume reduces the commission. A line carrying NO volume is never scaled on that basis: bundle expansion zeroes one side of a bundle deliberately and that side can still carry a real commission value, so reading zero as “all of it was discounted away” would erase it — at the cost of also leaving a line genuinely discounted to zero volume unscaled. Confirm the tenant’s ItemPrices rows carry CommissionableVolume before turning this on. |
order.commission_return_price_fallback | Commission enrichment: fall back to current prices on returns | false | — | When on, a return line the parent order does not carry is reversed from today’s ItemPrices instead. Off (default) leaves it unreversed, which is safer: prices may have changed since the sale. Only turn this on for a company whose parent orders are known to be incomplete. |
order.order_discount_line | Export order discount as line item | false | — | When on, any part of a Fluid order discount that is not already reflected in the exported line prices or in an exported payment is added as an extra negative-price Exigo line item, so the Exigo order total matches the amount paid. Requires an order discount SKU. |
order.order_gross_prices_with_promo_lines | Export gross prices with a line per promotion | false | — | When on, Exigo product lines carry the same unit prices Fluid shows and each promotion is exported as its own negative-price line named after the promotion, instead of the discount being subtracted from the product prices. Supersedes “Export order discount as line item”. Requires an order discount SKU. |
order.order_discount_sku | Order discount SKU | — | — | Exigo ItemCode used for the order discount line item, and for the promotion lines when gross prices are enabled. |
customer.duplicate_customer_handling | Duplicate customers | skip | skip, sync, hold | How to handle a customer that already exists in Fluid. |
customer.unverified_customer_handling | Unverified customers | mark_inactive | mark_inactive, sync, skip | How to handle a customer that has not completed verification. |
customer.default_customer | Default customer | \{"sponsor": "2", "enroller": "2"\} | sponsor, enroller | Default sponsor and enroller IDs for new customers |
customer.member_type_resolution | Resolve customer type from member type | false | — | Resolve the Exigo CustomerType, PayableType and tree placement from the Fluid member-type slug rather than the legacy role. Fluid filters role to admin/rep/customer/preferred_customer, so a seeded “preferred” tier or any custom member type arrives as the wrong type. Off by default because the mapping tables are what this reads: turn it on only once this company has a Customer Type row for every Fluid member type, and its Tree settings cover those same types. Without a row the export fails outright, and tree placement is applied once at create and is permanent in Exigo. |
customer.sync_contacts | Sync customer contacts | false | — | Enrich imported customers with their secondary contact records from ExigoWebContext.Contacts. Off by default because many Exigo sources (e.g. reporting replicas) do not expose that table, and a missing table fails the whole customer fetch. Turn on only for a source confirmed to expose it; customers import either way, just without their secondary contacts when off. |
customer.phone_source | Phone field | Phone | Phone, MobilePhone, Phone2, Fax | Which Exigo phone column this company uses. Fluid stores a single phone number; on import this column feeds the Fluid customer phone, and on export the Fluid phone is written back to this same column. The other phone columns are left untouched. |
customer.phone_mirror_columns | Phone mirror columns | — | Phone, MobilePhone, Phone2, Fax | Additional Exigo phone columns that receive the same Fluid phone number on export. This is export-only and does not affect which column feeds Fluid on import; configure that with Phone field. |
customer.lifecycle_terms_slot | Member terms-acceptance date field | None | None, Date1, Date2, Date3, Date4, Date5 | Optional. Which Exigo customer Date column records when the member accepted the current tier’s policies / terms. Stamped on member-type transitions (e.g. an upgrade to affiliate). “None” disables it. Exigo’s own “Date Entered” is never modified. |
customer.lifecycle_start_slot | Member start date field | None | None, Date1, Date2, Date3, Date4, Date5 | Optional. Which Exigo customer Date column records the member’s start date for the current tier. On an upgrade to affiliate it is overwritten with the became-affiliate date. “None” disables it. |
customer.lifecycle_downgrade_slot | Affiliate downgrade date field | None | None, Date1, Date2, Date3, Date4, Date5 | Optional. Which Exigo customer Date column records when an affiliate is downgraded back to customer. “None” disables it. |
customer.duplicated_customer | Duplicated customer strategy | newest | newest, oldest | How to handle duplicate customers during sync |
customer.skip_type_sync_after_create | Skip type sync after create | false | — | Skip customer type synchronization after initial customer creation |
customer.customer_changelog_sync | Customer changelog sync | true | — | Enable changelog-based polling for customer updates. When enabled, replaces standard customer delta sync after initialization. |
customer.customer_creation_sync | Customer creation sync | true | — | Enable polling for new customers created in Exigo. Disables V1 customer delta sync — enable customer_changelog_sync as well so updates continue flowing. |
customer.strict_status_mapping | Use customer status mappings as sync scope | false | — | When enabled, the Customer Status mappings define which customers sync: mapped Exigo statuses import, unmapped statuses are excluded at the source and never create a sync. Customers already in Fluid that move to an unmapped status are held for review rather than imported with a default status. Blank Exigo statuses remain in scope. |
customer.customer_creation_apply | Apply customer creation to Fluid | true | — | When enabled, new customers from Exigo are pushed to Fluid. When disabled, EntitySync records are created but not applied. |
customer.username_from_external_id | Set username to Exigo Customer ID | false | — | After a customer is created in Exigo, overwrite the Fluid username and the Exigo WebAlias with the new Exigo Customer ID. Fluid assigns a random username at signup; enable this when the Exigo Customer ID must be the username. |
customer.customer_constant_stamps | Customer constant stamps | — | — | Stamp a fixed value into an Exigo customer Field column on create. Each row can apply to affiliates, customers, or every member tier. |
customer.custom_field_metafields | Custom field metafields | — | — | Map Exigo custom fields (Field1-15 / Date1-4) to Fluid customer metafields (namespace / key / value_type). Only mapped fields are synced to Fluid. |
customer.email_consent_sync | Sync email marketing consent | false | — | When enabled, email opt-in/opt-out changes in Fluid are pushed to Exigo on customer update (OptInEmail / OptOutEmail). Create-time opt-in always applies regardless of this setting. |
customer.sms_consent_sync | Sync SMS marketing consent | false | — | When enabled, SMS opt-in/opt-out changes in Fluid are pushed to Exigo on customer update (OptInSms / OptOutSms). Create-time opt-in always applies regardless of this setting. |
customer.email_link_excluded_status_ids | Email link excluded statuses | — | — | Exigo CustomerStatuses that must never be matched by email when Fluid looks for an existing Exigo customer before creating one (e.g. Terminated). A match on one of these statuses is skipped rather than paired to, so a new signup reusing a former member’s email creates a new Exigo account instead of silently reattaching to the old one. Leave empty (the default) for unchanged behavior: every status is eligible to pair. |
tree.binary_placement_enabled | Binary placement | false | — | Send BinaryPlacementPreference when creating customers in Exigo |
tree.binary_placement_preference | Binary placement preference | 5 | — | Default binary placement preference for new customers |
tree.binary_tree_insertion_enabled | Insert into binary tree | false | — | Call PlaceBinaryNode after creating customers in Exigo, using the Fluid enroller as the parent and the binary placement preference as the placement type |
tree.tree_mapping | Tree mapping | — | — | Map external tree types to customer types |
sponsor_tree.sponsor_tree | Sponsor tree type | unilevel | enroller, unilevel | Which tree endpoint to use for sponsor data |
point_sync.points_export_enabled | Points export & sync | false | — | Enable Exigo Points debit, refund-restore, admin adjustments, and the Exigo→Fluid balance sync for this company. No-op when off. |
point_sync.points_default_account_id | Default Points account ID | — | — | Exigo PointAccountID used when no currency-specific mapping matches. |
point_sync.points_account_ids_by_currency | Points account IDs by currency | — | — | Map of ISO 4217 currency code to Exigo PointAccountID, e.g. { “USD”: 6, “CAD”: 7 }. |
point_sync.country_to_currency | Country to currency | — | — | Map of ISO country code to currency, e.g. { “US”: “USD”, “CA”: “CAD” }. Used to resolve the Points account for admin adjustments, whose webhook carries country_iso (not currency). |
point_sync.email_whitelist_enabled | Restrict sync to a whitelist | false | — | When on, the Exigo→Fluid balance sync and login-sync only touch customers whose email is in the whitelist below. Use for a phased rollout / testing (ported from the droplet). |
point_sync.email_whitelist | Email whitelist | — | — | Array of customer emails to sync when the whitelist is enabled, e.g. [“a@x.com”, “b@y.com”]. Matching is case-insensitive. Ignored when the whitelist is off. |
point_sync.slack_notifications_enabled | Slack sync reports | false | — | Post a per-run Slack summary (and failure alerts) for the Exigo→Fluid points sync. Ported from the droplet reporter. Off by default. |
point_sync.slack_webhook_url | Slack webhook URL | — | — | Slack Incoming Webhook URL to post the points sync reports to (same webhook the droplet used — posts as “Points and Rewards Reporter” into its bound channel). No bot token needed. Required for reports to send. |
