Product usage in the CRM

Build one output table per CRM object (company, contact, workspace as a custom object), with the CRM record id on every row. The id comes from the single-customer map, never from an on-the-fly name match. Contacts match by email, lowercased and trimmed.

Separate records that do not exist in the CRM yet (create) from those that do (update). The update routine never creates. The create routine first checks whether the email or domain already exists. Start creation with a small pilot (for example, 15 records) and check the record is still there a few seconds later: CRM anti-duplicate automations have deleted freshly created contacts.

Compare the calculated value with the current CRM value and send only the difference. Example: set active user to No only for people who are Yes in the CRM and became inactive in the product. Sending everything every day burns API quota, fires workflows for nothing and pollutes the property history.

Declare which properties the routine may write. Phone, email and tax ID are filled only when empty. Owner, stage and fields the team edits are never overwritten. Properties written by the routine get their own prefix (for example, lake_ or product_), so nobody edits them by hand.

Remove internal, support and service users (by role, email domain or list), test accounts and demo accounts from the calculation. A user enabled in a company with no current package or subscription is not an active user.

Plan, subscription status (active, past_due, canceled, trialing), MRR and first payment date come from billing, consolidated per customer and not per subscription. With several subscriptions, a declared priority rule picks the status. The first payment date is the date of the first paid charge, not the billing cycle date. Send the data's reference date along with it.

Write indicators the team actually uses (active users in 7 and 30 days, days since last login, modules in use, customer tier), not one field per event or feature. Picklist values are translated and come from a closed list. HubSpot caps a property at 512,000 bytes, and the contacts source fails above 10,000 nested fields; after 3 consecutive failures, it disables itself.

The Nekt destination writes properties by object id, but it does not associate contact to workspace, company to workspace or deal to workspace. Do that in a notebook that compares expected associations with existing ones and creates only the missing ones, with the association label. Run a dry run first: in a real case, two weeks of dry run showed hundreds of associations to create and more than a hundred contacts that did not even exist yet.

The routine checks the target portal or account before writing (sandbox in testing, the expected id in production) and stops if it does not match. It also checks volume: a catalog below the expected minimum or an unusual number of changes means broken source data, and the routine stops instead of deleting options or blanking fields. Every send goes to a log with record, value, result and error. API keys live in the secrets vault, never in code.

Include inactive and deleted accounts in the send, so status and exit date are updated in the CRM and in the support tool. Otherwise CS keeps seeing as active someone who already canceled.