Calculated field disappears after saving the record

Hi there,

I wanted to achieve the following : 

Our account records have a default solution architect (SA) picked from the Users module via Releated field.

When an opportunity is created , we want to take the choosen SA from the account as initial SA for the opportunity.

However, the user is allowed to change that opportunity SA afterwards.

So I've added a calculated text field Solution Achitect Ini to store the SA from the account.

(formula used is related($accounts,"solution_architect_c"))

The SA DOES appear during opportuntiy creation, but is erased when saving the opportunity.

How can I prevent this ?

My next step I planned was to create a User module based related field (Opportunity Solution Architect) on the opportunity and take the above mentioned field as default.

The ini field will stay hidden, The Opportunity Solution Architect field will be shown.

Am I on the correct track to achieve this ?

(I only have Studio and BPM available, PHP and the like is beyond my expertise)

Thanks for your assistance,

Hugo

  • Hi  ,

    You’re very close! The issue you’re hitting is a common one with calculated fields: they recalculate every time the record is saved, which means your solution_architect_ini_c gets overwritten with the current value from the Account — even if the user has updated it manually (technically because they are calculated they are actually not really editable).

    Since you want to:

    • Initialize it once at Opportunity creation,

    • But allow the user to change it afterwards without it being overwritten,

    A calculated field won’t work here.

    Best approach with Studio & BPM only:

    1. Move the formula from solution_architect_ini_c to solution_architect_ini_default_c and make solution_architect_ini_c a regular text (or related) field.

    2. Create a BPM Process Definition that:

      • Triggers only on new Opportunity creation,

      • Uses Start Event > Change Condition > New Records Only,

      • Add an Action > Change Field to set solution_architect_ini_c with: solution_architect_ini_default_c

      • This copies the value from Account only once at creation.

    Edit: I initially overlooked the core issue — just updated my response to reflect that.

    If you had file-level access, you could define the default field as non-db, which avoids storing it in the database at all — ideal for purely transient values.

    But considering your current access (Studio + BPM only), the BPM-driven copy approach from a calculated helper field is probably the cleanest option.

    — Tev

  • Thanks   for your swift reply.

    Tev, what I don't understand though is , that in my original setup , when creating a new opportunity the solution_architect_ini _c field shows the SA from Account (like intended) , but when saving that field is not overwritten with the re-read current Account SA (like you explained above)  but gets simply blanked/emptied. It would not harm my setup if it would catch the Account SA during creation and again during saving. 

    Also, what is the SugarCRM system 'timing' between recalculating fields and executing a BPM proces with trigger 'new record' ? What comes first ?

    Again, thanks for your help, I'll try your suggestion.

    :-)

    Hugo

  • Hi ,

    I had a similar need, and just having the field set for Audit wasn't satisfactory.  My solution probably isn't the best approach, but it works for me.

    I created a separate text field for the original value named "Initial Assignment", and I have a BPM copy the value from the related field for New Records Only (with a one minute delay after record creation).  In the Roles I set the field as Read-Only.

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)

  • Hi  ,

    Our newest release of Upsert BPM Essentials contains an enhanced 'Change Field' action for use within SugarBPM that meets this exact use case! With this new action you can copy user-based relate and relationship fields from one module to any other user-based field within that module or a related module. Here is what the action configuration looks like when updating the opportunity:

    Another feature of the new enhanced action is the ability to modify fields that are marked read-only. If you use SugarBPM a lot, the plugin has a lot of other great features to make automations more powerful and code-free. Please reach out via our website if you would like a demo of all the plugin has to offer!

    Chris

  • Thanks for the hint, Chris

    :-)

  • Hi  

    I tried your suggestion.

    Created the field solution_architect_ini_c as Relate (to User module).
    But when I created the process, the action to set that field , BPM does not offer solution_architect_ini_c as possible field in the list.

    Is that Change Field action possilble for all but Relate fields ?

    Thanks for you advice

    Hugo

  • Hi  ,

    Relate fields are not available to modify in the stock 'Change Field' action for SugarBPM. The feature I referenced below within our plugin makes relate fields based on the Users module available in our Enhanced Change Field action. I believe Tevfik's solution would only work with the native features if the field is a text field.

    Chris

  • Thanks Chris,

    I'll take a look at that Plug-In

  •   

    Hi Bud, I was wondering , 1 minute after record creation, does that mean after the new record appears on screen of after hitting Save ? In general, how does the time line for SugarCRM looks like ?

    When I start a new records the sequence is :

    1. all calculated fields are immediately calculated
    2. then all depending conditions in that record are evaluated
    3. all manual selections and inputs are done
    4. after hitting save SugarBPM evaluates if a process must be started (new record ? new and existing records ?, etc...)
    5. if the process encounters a timer, that timer is then started.
    6. when the timer has finished , the subsequent action is executed (what if there is a parallel gateway with a branch that completely kills the process before the timer ends ? )

    Is my assumption correct ?

    Bye now

    Hugo

  • Hi ,

    I'm sorry for the slow response.

    The "main" process is set for new records and all updates since it has multiple fields, and it triggers for other things that may change.  There are multiple parallel paths in the main process, and it normally finishes within less than a minute.  Since the default for record assignment defaults to the creator, the main BPM includes logic to set the assignment to the proper owner (and the correct Team).

    I could have included logic in the main process to copy the assigned user field to the text field, but since the process can be triggered for changes, I was lazy and didn't want to code the gateway logic for determining if the field should be copied.  I opted to make it a separate process that triggered on new records only.  The simple BPM logic is: Start-wait-copy-end. 

    P.S. I know that you can set the run order for multiple processes on the same record... I opted for a timer instead.

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)