How to restrict Editing the "Account" Field in Contact Records without coding

Hi everyone,

I'm looking for a way to prevent users from editing the "Account" Field in the Contact module. Ideally, i'd like to achieve this without custom coding.

I'm considering using a BPM Workflow to enforce this restriction. Is BPM the optimal solution for this use case ? If so, could you suggest the best approach to design the BPM process for this requirement ? 

Any insights, alternative solutions, or exemples would be greatly appriated ! :) 

Thanks in advance for your help.

  • Hi  , 

    Thanks for bringing this up!
    In most cases where the requirement is to restrict access or functionality for users, the best approach is to use Sugar's Teams and/or Roles framework.

    For your specific scenario, you can restrict editing the "Account" field in the Contact module with the following steps:

    1 - Navigate to Admin > Role Management and create a new Role, let's call it  "Account Name - Read Only"

    2 - Drill down into Contacts module 

    3 - Select the Account Name field and set it to Read-Only 

    4 - Add all the users that you want to see this restriction on. 

    This should be enough. 
    All the users that belong to that role will not be able to Edit the Account field in the Contacts module. 

    Let me know if this is what you are looking for. 

    Cheers, 

    André 


  • Hello  , 

    Thank you for your suggestion!

    To clarify, I would like to restrict users from editing the Account field after the Contact record is created. However, users should still be able to populate this field when creating a new Contact. Once the record is saved, the field should no longer be editable by regular users, but administrators should retain the ability to make changes if needed.

    Your suggestion works perfectly for the existing records in our instance, but it doesn’t address the creation of new Contacts. I’m looking for a solution that applies both to existing records and during the creation process for new Contacts.

    Let me know if you have any additional ideas or suggestions to achieve this!

    Thanks again for your help! Blush

  • Hi  

    To prevent users from editing the "Account" field in the Contact module, BPM workflows may not be the best approach since they are primarily designed for automating processes rather than restricting field access.

    Instead, you can achieve this by using Field Level Security or Role-based Access Control:

    1. Field Level Security: You can set the "Account" field as read-only or hidden for specific user roles, preventing users from editing it.

    2. Role-based Access Control: This allows you to restrict permissions, so only certain roles have the ability to edit the "Account" field, while others are restricted.

    Both options are easy to configure and don’t require custom coding.

    Bruce McIntyre

  • Hi  , 



    Thanks for the reply, this makes the requirement even more interesting.

    From my research, it seems there isn’t a straightforward way to achieve this without custom coding. However, I’ve identified an approach that requires minimal custom code, closely aligning with our documentation best practices.
    I hope this works for you. 


    Proposed Solution

    Since the account_name field in the Contacts module is a relationship field, it doesn’t support setting a conditional Read-Only formula in Studio.
    However, this can be achieved with a Custom Dependency Action, which involves a small amount of custom code. Here’s the step-by-step process:


    Step 1: Create a New Checkbox Field

    Add a new checkbox field in the Contacts module and name it lock_accountname_c.


    Step 2: Set the Field to Read-Only

    Configure the lock_accountname_c field to be read-only for all users by applying a custom role. This is similar to the method outlined in our previous example.


    Step 3: Implement a Custom Dependency Action

    Create a custom dependency action that makes the Account Name field read-only when lock_accountname_c is set to true. Here’s the code snippet you’ll need for this step:

    The file should be placed here: custom/Extension/modules/Contacts/Ext/Dependencies/account_name_read_only.php

    <?php
    
    $dependencies['Contacts']['readonly_fields'] = array(
        'hooks' => array("edit"),
        'trigger' => 'true',
        //Optional, the trigger for the dependency. Defaults to 'true'.
        'triggerFields' => array('lock_accountname_c'),
        'onload' => true,
        //Actions is a list of actions to fire when the trigger is true
        // You could list multiple fields here each in their own array under 'actions'
        'actions' => array(
            array(
                'name' => 'ReadOnly',
                //The parameters passed in will depend on the action type set in 'name'
                'params' => array(
                    'target' => 'account_name',
                    'value' => 'equal($lock_accountname_c,true)',
                ),
            ),
        ),
    );


    If your instance is on Sugar cloud this needs to be added via Module Loadable Package. 

    Step 4: Add the Fields to the Record View

    Once the fields are created and configured, add them to the Contacts module record view.

    Step 5: Create a BPM Process

    Implement a BPM process to automatically check the lock_accountname_c field after a record is created.
    The process might look something like this: 




    Outcome: 

    With this setup:

    Non-admin users can create Contacts and assign an Account Name during record creation, but they won’t be able to edit the Account Name afterward.

    Admin users will have the ability to uncheck the lock_accountname_c field, allowing edits to the Account Name, and can lock it again when necessary.



    Here's a video of how it would look like: 








    Let me know if this helps or if you need assistance on packaging the dependency to add it to your instance. 



    Cheers, 

    André 


  • Interesting solution,  ! Is it safe to say that users could still inadvertently change the account name via the Contacts subpanel on Accounts?

    Chris

  • Hi Chris! 

    Exactly right—thank you for including that remark!

      - 

    As Chris mentioned, users will still have the ability to “Remove” the relationship with the Contact from the Accounts record view subpanel or link a new Contact to it.






    When that happens, the account_name field will be updated as well as it updates the relationship. 

    If that's a problem, we could restrict this subpanel actions as well, but that would require more custom coding.