Can i ensure all Contacts under an Account automatically get assigned to the Account's Assigned To/User?

Hi Team,

When you create Contacts from an Account (record) by using the + button, the contacts are automatically assigned to whoever is adding it. I would like to know if you guys know of any way that we can ensure they are Assigned to the Assigned user of the Account?

Thanks,

  • Hi Peter Pavisic,

    A business rule does not run on it's own. It must be used in an Action element of a Process Definition. The Process Definition targeting Contacts module will have a Start Event that will have trigger criteria evaluated when a Contact is saved.

    Import my example .bpm file into your Process Definitions module and, when prompted, check the checkbox to include the Business Rule as well.

    I mention all this just in case you, as a new administrator, are mistakenly expecting the Business Rule to be a stand-alone automation. It is not.

    Here is a link to the Action documentation section describing how to incorporate a Business Rule into a Process Definition.

    Edit: Also, as an alternative to written documentation on feature behavior, I made this YouTube video series covering the feature behavior available in Advanced Workflow in 8.3.0. The feature name changed to SugarBPM and additional functionality was added in 9.0.0 that is not covered in this series. The titles of the videos in the series point out the focus. For example, this video focuses on Business Rules.

    I hope this helps!

  • With a variety of different approaches here I would like to add my own.

    I implemented this by leveraging the SetValue from the dependency actions framework. 

    This was my code for the Opportunities module, you just need to adapt it to use in a different module. 

    custom/Extension/modules/Opportunities/Ext/Dependencies/inherit_account_assigned_to.php

    <?php
    
    $dependencies['Opportunities']['populate_assigned_user'] = array(
        'hooks' => array("edit"),
        'trigger' => 'greaterThan(strlen(related($accounts,"assigned_user_name")),0)', 
        'onload' => 'true', 
        'actions' => array(
            array(
                'name' => 'SetValue',
                'params' => array(
                    'target' => 'assigned_user_id',
                    'value' => 'related($accounts,"assigned_user_id")'
    
                )
    	),
    	array(
                'name' => 'SetValue',
                'params' => array(
                    'target' => 'assigned_user_name',
                    'value' => 'related($accounts,"assigned_user_name")'
    
                )
            )
        )
    );


  • Seeing this thread resurrected, I figured I would offer one more solution that doesn't involve any custom coding. One of the many features of Upsert BPM Essentials allows you to inherit user relationships from parent records and gives you full access to modify the behavior as business requirements change. With this specific feature, you can:

    • Inherit different relationships for different records (e.g. technical support cases route to their assigned support rep, account maintenance cases route to their assigned customer success rep, all contacts route to their sales person, etc.)
    • Define backup routing scenarios for when an intended user is unavailable

    The dynamic capabilities of the feature allow you to enhance your customer experience so that the right people get the information they need immediately. 

  • it seems all your wondefully helpfull videos have be removed from YouTube, and also the images and BPM mentioned in your replies here as well

    are you able to recover these please?

  • are you able to recover these please?

     - I've been checking since I saw your question and have been unsuccessful so far. Without going into too much detail, when we migrated from our old community site to SugarClub ~2 years ago, some images did not migrate successfully, but that was not caught until the original images were no longer accessible. Sometimes there are exceptions to this, but not always. 

    Unfortunately, SugarBPM is not my strong suit, but I'll ask around internally if anyone has any suggested updates to this thread (and if any updates to SugarBPM in the last 3+ years would come into play).

    I'll also mention, not specific to this use case, that many of the Help Articles on SugarBPM include example templates that can be imported into your instance and configured to your needs (e.g.: https://support.sugarcrm.com/Knowledge_Base/SugarBPM/Using_SugarBPM_for_Territory-Based_Lead_Assignment/#Downloads).

  • In current versions of SugarBPM, a Start Event can be set to react to a Relationship Change.

    Then, a Change event can be configured to change the Assigned To field.

    To achieve the goal of ensuring all Contacts were assigned to the Account owner when creating a new Contact, I

    1. made a process definition targeting Accounts.
    2. configured the Start Event to apply to Relationship Change and criteria for Contacts Added
    3. added a 1-minute Wait Event (to ensure the new Contact's relationship was established before trying to change its field values)
    4. added a Change Field action that set the Assigned To field in all related Contacts to Record Owner
    5. added an End Event doing nothing.

    With the BPM scheduler running, every Contact including the one I just created is assigned to the Account's owner during the next scheduler run.

    Note: Without the Wait Event, all Contacts except the one just created are updated, but the new Contact is not updated.

  • Hi - those videos are gone, but they were quite outdated as well. I just offered a new top comment in this thread providing a description for how this use case can be achieved with modern SugarBPM functionality. 

  • One thing to note about this configuration is that SugarBPM will save all related contacts to the account regardless of whether the assigned user needs updated on each contact. While the account::contacts relationship is typically a relatively small number of records, this solution could cause performance issues for more robust relationships.

    Another potential issue is that re-saving records may cause additional logic (e.g. Sugar Logic, SugarBPM, logic hooks, etc.) to trigger unexpectedly. 

    If either of these are a concern, you should consider alternatives where only the child record being created/related to the parent record is updated rather than all records within the relationship.

  • Hey ,

    I experienced this feature request in lots of projects. maybe it is time to create an enhacement request for a system setting that allows to set the assigned user accordingly to (specified per module) attached records :-)

    Bests
    Björn