Problem with triggering BPM process

I have a relate field in Opportunities called Assigned Engineer that's related to the Users module. In the database, this field is saved as opportunities_cstm.user_id_c. I'm trying to set up a SugarBPM process that will be triggered when a user with a role of "Engineer" will be saved in the Assigned Engineer field. The problem is that relate fields are not available among the starting event triggering criteria. To solve this, I created a start event with a criteria "record owner has the role of Engineer". Then, I manually converted the record owner to Assigned Engineer by following Patrick McQueen's reply to this post. Specifically, I found the record corresponding to the start event of this process in the pmse_bpm_event_definition table and changed the evn_criteria field from

[{"expType":"USER_ROLE","expLabel":"Record Owner has role of Solution Architect","expValue":"481782a6-37d1-11ea-b3d4-0800270fcb6c","expOperator":"equals","expField":"owner"}]

to

[{"expType":"USER_ROLE","expLabel":"Assigned Engineer has role of Engineer","expValue":"481782a6-37d1-11ea-b3d4-0800270fcb6c","expOperator":"equals","expField":"{::Opportunities::user_id_c::}"}]

This does not trigger the process. (When I save an Assigned Engineer, the process does not appear in Process Management.) I tried entering the relate field as "expField":"{::user_id_c::}" or "expField":"user_id_c", all with no effect. I'm guessing the problem is that this JSON does not specify which module the relate field is related to. The post referenced above shows the syntax for specifying a relate field in the pmse_bpm_activity_definition table. But how can I do the same thing in the pmse_bpm_event_definition table?

  • Hi Yury Voloshin,

    My answer to the other post was specific to the stock Assigned to relationship.

    If the field is saved as opportunities_cstm.user_id_c, that sounds like a custom Relate-type field, not a relationship.

    This document discussed the difference.

    I am right now building out the test scenario you described above to use a custom relate-type field to find out what I learn from that, hoping to help you with this different scenario.

    I will follow up shortly.

  • Hi Yury Voloshin,

    I do not believe my advice in the linked post applies to this scenario for a few reasons:

    1. The value in the Relate-type field does contain the ID number of a User record, but there is no established relationship between the target record (Opportunity) and the identified User record. I recommend using a custom relationship, not a relate-type custom field for this goal.
    2. Even if you use a relationship instead of a relate-type field, the goal as described is essentially an attempt to make criteria based on a three-module chain: Opportunities -> Users -> Roles. This related-to-related is not currently supported in Start Event criteria or Receive Message Event criteria.
    3. The "expType":"USER_ROLE" function appears tied the subset of pre-defined, hard-coded user relationships: 
    4. The syntax: {::Opportunities::user_id_c::} is available as a variable for "expValue", not for "expField".

    The closest I was able to get to solving this did not involve directly the database at all:

    1. Create a custom relationship between Users and Opportunities (one-to-many)
    2. Create a customer "Role" TextField in Users module.
    3. Set the Module Field Evaluation to read the related User record's custom Role field, as show here:

    Alternatively, keep in mind Enrico Simonetti's post about extending SugarBPM (previously called Advanced Workflow).

  • Thank you Patrick McQueen! I really appreciate the help. I'm now trying to implement your suggestion about using a relationship instead of a relate field. I created the one-to-many relationship between Users and Opportunities, as well a text field Roles in Users module. Next, I realized that in order for this process to work, the Roles field has to store a list of the user's roles. In order to do that, I made Roles a calculated field having "related($aclroles,"name")" as the calculation formula. This is where I ran into a problem. Most users have more than one role. For example, a user might have "Non-admin User", "Engineering", "Leadership" roles. But, the Roles field displays only one of these roles, such as "Engineering". Same problem occurred when, instead of using roles, I tried to use teams. I converted the Roles field to a calculated Teams field with a formula "related($team_memberships,"name")". Now, when the user is a member of several teams, the Teams field displays the name of only one of these. Is there a way to list all the related records in a calculated field instead of just one?

  • Hi Yury Voloshin,

    There is nothing I am aware of in the core product that can meet your described use case. Personally, I would build a logic hook to iterate through the related Roles and either just do the BPM process's desired action, or collect the Roles into a field somehow and then have the BPM process evaluate whether that field contains the value I seek.

    I hope this helps!

  • Thank you Patrick! This does help. A logic hook was going to be my next try and its good to have a confirmation that this is the right course of action.

    Best regards,

    Yury