How to Automate Calculations in Method CRM Using the Action Editor - PART 4

A Method CRM screen is only useful if it reduces work for the person using it.

In the last part of this series, we added services to a potential deal using an editable grid. Each service line had its own amount, but the total amount at the top of the deal was still sitting at zero. That is the kind of small gap that turns into bad data quickly.

A user can add the line amounts manually, but that defeats the point of building a custom workflow. If Method already has the line items on screen, Method should be able to calculate the total and update the deal automatically.

That is where the Method CRM Action Editor comes in.

In this walkthrough, I will show you how to use the Action Editor to loop through the service lines on a potential deal, add up the amounts, update the main amount field on screen, and save the correct total back to the Opportunity record.

This is Part 4 in the Method CRM custom app series. The example uses a potential deal screen, but the same pattern applies to quotes, service jobs, project lines, order details, or any screen where you need to roll up child records into a header field.

What the Action Editor Does in Method CRM

The Action Editor is Method CRM's visual automation builder.

It is where you define what happens when a user clicks a button, saves a record, changes a value, opens a screen, or triggers a custom action. You are not writing code, but you are still building real business logic.

Inside the Action Editor, you can chain together actions like:

• navigate to another screen
• save records
• update controls on the current screen
• assign values to action results
• run math functions
• loop through grids
• loop through tables
• call another routine
• update records in a table

This is why the Action Editor is one of the most important parts of Method CRM customization. Screens give users a place to work. The Action Editor makes those screens do the work with them.

For this example, the goal is simple:

• look at every service line in the grid
• read the amount on each line
• add those amounts together
• place the total into the main Amount field
• save the deal with the correct amount

That sounds small, but it is a core automation pattern. Once you understand it, you can reuse it across almost any Method CRM build.

Why the Total Should Not Be Entered Manually

Manual totals create three problems.

First, they slow the user down. If someone adds three services to a deal, they should not have to grab a calculator or do mental math before saving.

Second, they introduce mistakes. A single missed line item or typo can throw off the opportunity amount, which then affects reporting, forecasting, and follow-up.

Third, they create a disconnect between the line items and the header record. If the service lines say one thing and the opportunity amount says another, nobody knows which number to trust.

A better Method CRM workflow calculates the total from the source data. The service lines already know their amounts. The main deal amount should be derived from those lines.

That keeps the screen faster, cleaner, and more reliable.

Start With a Hidden Function Button

The first step is to create a hidden button that will hold the calculation logic.

This is a pattern I use often in Method CRM. Instead of putting all of your logic directly inside the Save button, create a separate hidden button and treat it like a reusable function.

For this example, the hidden button is named:

fnc_CalculateAmount

The fnc_ prefix makes it clear that this button is not meant for the user to click. It is a function-style button that stores reusable logic.

To create it:

1. Open the potential deal screen.
2. Click the dropdown beside the screen name.
3. Choose Customize Screen.
4. Go to the hidden section of the screen.
5. Add a button control.
6. Name it fnc_CalculateAmount.
7. Open that button's click action in the Action Editor.

The reason for using a hidden function button is maintainability.

If the calculation ever changes, you only update it in one place. Any button that calls fnc_CalculateAmount automatically uses the updated logic. That is much better than copying the same calculation into Save, Save and Back, duplicate save buttons, and other screen actions.

Good Method CRM builds are not just about making something work once. They are about making it easy to maintain later.

Create an Action Result for the Running Total

Before looping through the grid, create a variable to hold the running total.

In Method CRM, this is done with the Assign Value to Action Result action. An Action Result works like a temporary variable inside the action sequence.

Create an action result called:

result_amount

Set its starting value to:

0

This matters because the calculation needs a clean starting point every time it runs. If you do not reset the value first, you risk adding new amounts onto an old value from a previous action run.

The logic starts like this:

• create result_amount
• set it to zero
• loop through the service lines
• add each line amount into result_amount

By the end of the loop, result_amount will contain the full total.

Use Loop Through Grid, Not Loop Through Table

Next, add a Loop Through Grid action.

This distinction matters.

Method CRM has actions for looping through a grid and looping through a table. They sound similar, but they are not the same.

Loop Through Table reads records from the database. That means it works with records that already exist in the table.

Loop Through Grid reads the rows currently shown in the grid on screen. That includes rows the user may have just added but has not saved yet.

For this calculation, Loop Through Grid is the right choice.

If a user adds a new service line and immediately clicks Save, that new row may not exist in the database yet. If your automation loops through the table, it can miss the unsaved row. If it loops through the grid, it sees what the user sees on screen.

That is exactly what we want.

Configure the Loop Through Grid action to use the potential services grid. If Method shows an option to only select rows that are checked, leave it unchecked for this use case. The total should include all service lines, not only selected rows.

At this point, the structure is:

1. Set result_amount to zero.
2. Loop through the potential services grid.
3. Run math inside the loop.
4. Update the amount field after the loop finishes.

Add Each Line Amount to the Running Total

Inside the Loop Through Grid action, add a Math action.

Set the math function to Add.

Because the Math action is inside the grid loop, Method exposes loop values from the current row. One of those values should be the line amount from the grid.

Use the line amount as the first value. Use result_amount as the second value. Store the result back into result_amount.

The calculation works like this:

• Start with result_amount = 0.
• First row amount is 500.
• 0 + 500 = 500, so result_amount becomes 500.
• Second row amount is 440.
• 500 + 440 = 940, so result_amount becomes 940.
• Third row amount is 180.
• 940 + 180 = 1120, so result_amount becomes 1120.

The loop repeats until it has processed every row in the grid.

This is the loop-and-accumulate pattern. You initialize a value, loop through a set of records or rows, add each relevant value into the running total, and then use the result after the loop completes.

It is one of the most useful patterns you can learn in the Method CRM Action Editor.

Update the Amount Field on Screen

After the loop finishes, add an Update Controls on Screen action.

Point it at the main Amount field in the potential deal header. Set that field's value to result_amount.

This updates the visible Amount field on the screen with the total you just calculated.

At this stage, you are not directly updating the Opportunity table. You are updating the control on screen. That is intentional.

The Save action will handle writing the screen values back to the table. If you update the table directly inside the calculation function, you can make the save flow harder to reason about. For this workflow, the cleaner pattern is:

1. Calculate the amount.
2. Update the Amount control on screen.
3. Run Save All.
4. Let Save All write the current screen values to the database.

That keeps the calculation logic separate from the persistence logic.

Call the Calculation Before Saving

Now the calculation function exists, but nothing is calling it yet.

Open the Save button in the Action Editor. Before the Save All action, add a Call Routine action that calls fnc_CalculateAmount.

The order matters.

The correct order is:

1. Call Routine: fnc_CalculateAmount
2. Save All

Do not save first and calculate second.

If Save All runs before the calculation, Method saves the old amount. Then the screen updates after the save, which means the database can still be wrong. The calculation must run first so the Amount field on screen has the correct value before Save All writes the record.

This is one of the most common places where Method CRM automations break. The actions may all be correct, but the order is wrong.

When you are building in the Action Editor, always think through the sequence:

• What value exists right now?
• What action changes it?
• When does the save happen?
• Which value is being saved?

Order of operations is not a technical detail. It is the workflow.

Reuse the Save Logic From Save and Back

If the screen has both Save and Save and Back buttons, avoid duplicating the same save sequence in both places.

A cleaner approach is to make one button responsible for the core save routine, then have the other button call it.

For example, the Save button can handle:

1. Call fnc_CalculateAmount.
2. Save All.

Then the Save and Back button can call the Save button's routine and handle any navigation after that.

This keeps your screen logic centralized. If you later add validation, change the calculation, or adjust save behavior, you do not have to remember every button that might save the record.

That matters on real Method CRM builds because screens tend to grow. What starts as one save button often becomes Save, Save and Back, Save and New, Approve, Convert, Send, or other custom actions. If each one contains its own copied save logic, the screen becomes harder to maintain.

Reusable routines keep the build clean.

Disable the Calculated Amount Field

Once the Amount field is being calculated, users should not manually edit it.

Set the Amount field's load state to Disabled.

This still lets users see the calculated total, but it prevents them from overriding it by hand. That is the right user experience for a derived value.

If a user needs to change the amount, they should change the line items. The total should come from the lines.

This protects the integrity of the data model:

• service line amounts are the source
• the opportunity amount is the calculated rollup
• users cannot create a mismatch by typing over the rollup field

Small controls like this make a big difference. A good Method CRM screen guides the user into the right behavior instead of relying on training alone.

Hide the Function Button Section

Because fnc_CalculateAmount is only there for automation, it should stay hidden from users.

Set the hidden section's load state to Hidden.

This keeps the front-end screen clean while preserving the reusable logic behind the scenes. Users should see the workflow they need. They do not need to see every helper button, temporary variable, or automation control used to make that workflow function.

That separation is a normal part of good Method CRM customization. The user-facing screen should be simple. The hidden section can hold the supporting controls that make the screen smarter.

Test the Full Save Flow

After the automation is built, test it like a real user.

Open the potential deal and confirm that the Amount field starts at zero or the current saved amount. Add service lines to the editable grid. Confirm the line amounts are correct. Click Save.

The Amount field should update immediately with the total of the service lines.

Then leave the screen and reopen the same potential deal. The calculated amount should still be there because Save All wrote the updated screen value back to the Opportunity table.

Also test changes:

• add a new service line
• change a quantity
• change a rate
• remove or clear a line if that is part of the workflow
• save again

The total should recalculate based on the current grid values every time.

Do not only test the happy path. Test the way users will actually work. That is where you catch sequencing problems, missed rows, and save paths that do not call the calculation routine.

Common Mistakes to Avoid

Using Loop Through Table when the rows are not saved yet

If the user has just added a new grid row, Loop Through Table may not see it. Use Loop Through Grid when the calculation needs to include what is currently on screen.

Forgetting to reset the action result to zero

Always initialize the running total before the loop. Otherwise, the calculation can reuse an old value and produce the wrong total.

Putting the math action outside the loop

The Math action needs to run once for each row. If it is outside the Loop Through Grid action, it will not process the grid rows correctly.

Saving before the calculation runs

The calculation must happen before Save All. If the save happens first, the old amount can be written to the database.

Updating the table directly when updating the screen is enough

For this workflow, update the control on screen and then let Save All write the value. That keeps the logic cleaner and easier to maintain.

Leaving the calculated field editable

If the Amount field is a rollup from line items, disable manual editing. Users should update the source lines, not overwrite the calculated total.

Why This Pattern Matters

This example is about calculating a potential deal amount, but the pattern is much bigger than that.

The same structure can be used to:

• total quote line items
• calculate estimated project value
• roll up service charges
• count selected rows
• summarize quantities
• calculate weighted scores
• update header records from child rows
• prepare values before saving a record

Most useful CRM automation is not complicated. It is a sequence of small reliable steps:

1. Start with a known value.
2. Read the records or rows that matter.
3. Apply the business rule.
4. Put the result where the user needs it.
5. Save it in the right order.

That is exactly what the Method CRM Action Editor is good at.

When you learn how to combine hidden function buttons, action results, grid loops, math actions, update controls, and Save All, you can build screens that behave like real business applications.

Final Thoughts

The Action Editor is where Method CRM becomes more than a set of screens.

In this example, the user adds services to a potential deal and clicks Save. Behind the scenes, Method loops through the grid, totals the service amounts, updates the main Amount field, and saves the correct value to the Opportunity record.

That is the kind of automation that makes a custom Method CRM app worth using. It removes manual work, protects the data, and keeps the workflow moving.

If your Method CRM screens still rely on users to manually calculate totals, copy values between fields, or remember the right save process, there is a better way to build it.

Crafting Clouds helps businesses turn Method CRM into clean, workflow-driven systems that match the way their teams actually operate. If you want help designing or improving your Method CRM setup, book a free strategy call and let’s map out what should happen next.