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

Hello Andre Serrazina , 

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! 

Hi Phuong Trinh , 

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é 

Hi Phuong Trinh , 

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, Andre Serrazina ! Is it safe to say that users could still inadvertently change the account name via the Contacts subpanel on Accounts?

Chris