Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Field Security would be great for particular roles (sales manager etc) but not for "context aware" scenarios eg for the owner of the record.</p> <p>Your best bet would be to create a custom entity for Password, make the primary field (name by default) NOT business required.</p> <p>Create an N:1 relationship to Account, make the relationship "Parental" and make the lookup field Business Required. You will now see "Password" in the left navigation of the Account.</p> <p>Edit Password form to have lookup to Account, and add text field for the password itself, and make the "name" field not visible by default so you can ignore it.</p> <p>Create a security role (or edit existing ones) to give User level access rights to Password for the read, create, update, assign, and append privileges. Amend sales manager role to allow to read all Password records.</p> <p>The parental relationship will mean that if an Account is re-assigned then so will the child Password record. But, someone could create a password record (so they own it) and link it to an Account (even one they don't own, possibly), without changing the owner to match the parent. So, create a workflow on the Password record create, re-parent or re-assign which will change the owner to the same as the parent account to tidy up this situation.</p> <p>Edit the associated view for passwords to show the password field. Edit other views as required. (If you really want password visible on the Account form directly, use an inline grid set to use a minimum of space, no view selector etc. Still takes up far too much though, in reality.)</p> <p>Hope this helps</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload