- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
GoHighLevel’s Math Operation workflow action lets you add, subtract, multiply, or divide a number stored on a contact or opportunity, and do the date-math equivalent — add or subtract days, months, or years — on a date field. Used correctly, it replaces a Zapier step or a custom app for the handful of jobs agencies actually need: a lead score that rises and falls with behavior, a renewal countdown, an appointment or usage counter. Used carelessly, it silently corrupts the field it writes to, because three of its defaults are not what most builders assume.
This is a setup guide for the action itself, not a general workflow tutorial. It covers where the action lives, the field-type rule that breaks builds that ignore it, the behavior difference between numeric, monetary, and date fields when a calculation goes negative, and a documented contradiction in HighLevel’s own support articles that you should verify in your own account before you rely on it.
Where the action lives
Open Automation → Workflows, open the workflow you want to add it to (or start a new one), click the + to add a step, and search for Math Operation in the action list. It sits alongside Update Contact Field and Update Custom Values — all three write to a field, and it is easy to reach for the wrong one. Update Contact Field sets a field to a fixed or dynamic value; Math Operation is specifically for calculating a new value from an existing one.
The field-type rule that breaks builds
Every Math Operation action has two field slots: the field you are reading from (Select Field) and the field you are writing the result to (Update Field). HighLevel’s own documentation is explicit about the constraint: the Select field and the Update field can be the same field or two different fields, but they have to be the same field type. A numeric custom field can update another numeric field. It cannot update a monetary field, and it cannot update a date field, even though all three look like a field with a value in the picker.
Three field categories are available:
- Numeric custom fields — whole numbers or decimals, positive or negative.
- Monetary custom fields — currency values, with a floor at zero (see below).
- Date fields — either a custom date field you created, or one of the system dates such as Current Date or Date of Birth, used as the basis for adding or subtracting days, months, or years.
Custom Values — the static, account-wide placeholders under Settings → Custom Values — can be used as a fixed input to a calculation, but they are not a valid Update Field target; the action writes to contact or opportunity fields, not to account-level values.
Building a lead score field, step by step
A lead score is the most common reason agencies reach for this action, and it is a good illustration of the mechanics:
- Create a numeric custom field on the contact — for example Lead Score — and set its default value to 0 so every new contact starts from a known baseline instead of a blank value the math action cannot operate on.
- In each workflow that represents a scoring event (opened a specific email, clicked a link, booked a call, went cold after 14 days with no reply), add a Math Operation action.
- Set Select Field and Update Field to Lead Score.
- Choose the operator — Add for a positive signal, Subtract for a negative one — and enter the point value: +10 for a call booked, +5 for an email open, -5 for 14 days of silence.
- Publish the workflow and trigger it on a test contact before turning it on for real traffic. Check the field value after the run, not just the workflow’s execution log — the log confirms the step fired, not that it wrote the number you expected.
Once the field is live, feed it into an If/Else action elsewhere in your automation — score above a threshold routes to a sales-ready pipeline stage or an internal notification to a closer, score below a threshold stays in nurture. The Math Operation action does the counting; If/Else does the routing. Keep them as separate steps rather than trying to make one action do both.
What happens when the result goes negative — and why it differs by field type
This is the part that catches builders who assume a field is a field. A subtraction that pushes the result below zero behaves differently depending on which field type you are updating:
| Field type | Result below zero | Practical effect |
|---|---|---|
| Numeric | Allowed — negative values are stored as-is | A lead score can legitimately go negative, which is usually what you want for a decay model |
| Monetary | Floored at zero | A credits or usage-remaining balance built on a monetary field cannot go negative even if the logic says it should — the field just stops at 0 |
| Date | Not supported | Date math that would resolve to an invalid or negative result should not be assumed to work; treat it as a case to test explicitly |
If you are building anything where going negative is meaningful — a usage balance that should trigger an overage charge, for instance — do not build it on a monetary field and assume the negative value is there to react to. Use a numeric field instead, or add an explicit If/Else check before the balance would go negative.
Renewal and expiry countdowns with date math
For a renewal reminder, the date side of Math Operation pairs with a custom date field you already store — a contract start date, a policy renewal date, a subscription anniversary. A typical build: Math Operation reads the custom date field, subtracts a fixed number of days (say, 30), and writes the result to a second custom field such as Renewal Reminder Date. A separate workflow then triggers off that computed date to send the reminder. This two-field pattern — one field holding the real date, a second holding the computed trigger date — is worth keeping even though it costs an extra custom field, because it keeps the original record untouched if you ever need to recalculate with a different lead time.
One operation per action, or several — verify this in your account
HighLevel’s own support documentation is not consistent on a point that matters for how many steps your workflow needs: one current article describes an Add Operator control that lets you chain a sequence of calculations inside a single Math Operation action, while another current article states plainly that each Math Operation action performs one operation at a time, and that multi-step calculations require separate, sequential actions with the intermediate result stored in a field between them. Both pages are live on HighLevel’s support portal as of this writing.
Do not assume either behavior. Open the action in your own workflow builder and check whether an Add Operator option is present next to the operator dropdown. If it is not there, build multi-step math as a chain of separate Math Operation actions, each reading the field the previous one just wrote. This is also the safer default for readability: a workflow log that shows three discrete math steps is far easier to debug than one action hiding three operations inside it.
Gotchas worth testing before you trust the number
- Concurrent workflows writing to the same field. If two different workflows can both fire for the same contact around the same time — a common setup when scoring events come from several triggers — they can race to update the same field. Keep the set of workflows that touch a given scored field short and named consistently so you can audit what writes to it.
- Decimal precision. Division in particular can produce a long decimal. HighLevel’s documentation notes automatic decimal handling but leaves the exact rounding rule unstated; if a field is customer-facing (displayed on an invoice or portal), check the actual stored value after a division step rather than assuming it rounds the way you expect.
- A blank source field. A Math Operation reading a numeric field that has never been set is not the same as reading a zero. Give every field a default value at creation, as in the lead-score example above, so the first calculation a contact ever runs through has something valid to operate on.
- Re-entry settings on the workflow. A scoring workflow that a contact can re-enter will re-run the math each time. If that is not the intent — a one-time +10 for first call booked, for example — check the workflow’s re-entry setting rather than relying on the math action itself to prevent double-counting.
Frequently asked questions
Answers to the questions that come up once agencies start using this action for something other than a one-off calculation.
Can Math Operation update an opportunity's custom field the same way it updates a contact field?
The action is built around contact and opportunity custom fields, and the Select Field / Update Field pairing works the same way on either object — the constraint is that both fields still have to match in type. Confirm in your own account which object types appear in the field picker for the specific workflow you're building, since availability can depend on the workflow's trigger.
Why did my lead score field stop decreasing below zero?
It's almost certainly built on a monetary custom field rather than a numeric one. Monetary fields floor a negative result at zero, so a subtraction that should push the score negative just stops at 0 instead. Rebuild the field as a numeric custom field if you need it to go negative.
Does Math Operation support more than add, subtract, multiply, and divide?
For numeric and monetary fields those four are the operations available. For date fields the equivalent operations are adding or subtracting days, months, or years rather than arithmetic in the usual sense — there's no multiply or divide on a date.
Is there a simpler way to do a one-time point increment without Math Operation?
Update Contact Field can set a field to a fixed value, but it can't add to whatever value is already there — it overwrites. Math Operation is the action built specifically for read-the-current-value-and-calculate, which is what a running score or counter needs.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.