[SalesForce] Dynamically get result of a VF field’s formula, using Apex

How can I get the result of a formula ("field update"/"workflow rule"), in Apex, without hard-coding it?

There is a field whose value (calculated on upsert) is the formula result. I have dismissed inserting a new record or updating a dummy record to get the solution, because the complexity of the org would have unacceptable ripple effects.

To answer responses asking why… My Apex function is used by a visualforce page to dynamically display the formula result (as the user is typing, not during submission).

To answer responses directing to meta data… I need to be able to calculate the formula's result, not just access the formula's text.

Thank you very much in advance.

Best Answer

I do not think this is possible. My understanding is that formulas are always calculated when a record is retrieved so even if the field were available (say duplicated on the object in question) the value would not be accurate.

I think you will have to code a copy of the formula into your controller and have the controller do the calculation for you.

Related Solutions

[SalesForce] Formula fields and trigger

You might double check you're doing an after trigger. For before triggers, the trigger context has the new values for the trigger object loaded, but nothing has been committed yet, so any calls to the database will return the old values for both formula fields and regular fields. In after triggers this is not the case.

Imagine the following trigger

trigger Example on Account (before update, after update) {

  system.debug('==>trigger.new[0].name: ' + trigger.new[0].name);
  system.debug('==>trigger.old[0].name: ' + trigger.old[0].name);
  system.debug('==>queried: ' + 
               [select name from Account where id = :trigger.new[0].id][0].name);

}

Then imaging the following code

Account account = new Account(name = 'Hello');
insert account;
account.name = 'World';
update account;

For the update you'd expect the following output

/* Before Trigger */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: Hello

/* After Trigger */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: World

Things can get stranger if you something causes a second round of trigger execution, such as a field update. The values are what you'd expect for the first round, but the second round you'd expect trigger.old[0].name to match the queried value in the before trigger, but that's not actually the case.

/* Before Trigger - Pre Workflow */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: Hello

/* After Trigger - Pre Workflow */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: World

/* Before Trigger - Post Workflow */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: World

/* After Trigger - Post Workflow */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: World

[SalesForce] Cumulative Total for a Field

There's several possible solutions.

Option 1

Build this with the process builder. When the status changes to started, set the Start Time field, and when it the status goes back to stopped, simply add the difference in time to the Total Time field. This would require about two Process Builder entries. The drawback is that you won't have the sub-totals available to you (e.g. there were three appointments, one for 15 minutes, one for 20 minutes, and one for 17 minutes).

Option 2

Create a related custom object with a master-detail relationship and a rollup summary field. When the appointment starts, set the Start Time field. When the appointment ends, create a new child object with the Start Time and Current Time; a formula on this child calculates the time, then triggers the rollup summary to calculate the total time. The only real drawback here is that it'll cost more storage space.

Option 3

Create a bunch of fields, like 4 or 5 sets of appointment times. Set each one appropriately. Of course, the drawback here is what to do when you overflow the designed limit. Reporting is also slightly more complicated with this design.

Option 4

You could build a running total in a long text area and process the total time via a trigger. Reporting will suffer (e.g. you can't easily report on appointments of X length), but you'll still save storage space and be able to store a large number of appointment events.

I could go on and on, but I think you get the idea. You need to choose between reportability, storage requirements, and complexity. With the number of options available, I'm pretty sure you can find something that fits your needs.