Visibility to Child Level Records in Salesforce vs. Siebel

In typical CRM systems, attachments are typically the “children” of some parent entity. Visibility enablers at the child level are often implemented as an after-thought in CRM systems, and that tends to cause multiple issues with the way they are used.

Take Siebel CRM for example. Siebel not only allows you to control visibility at the parent level, but also enforce it at the child level. For example, you have access to Contacts *may* not automatically translate into access to Activities for that Contact. Out of the box the application allows you access to all Activities if you drill down to Contact > Activities, but you can specify the visibility at the View web template item level to control what the user sees as Activities for the Contact.

Specifying visibility at the child level in Siebel is done by a simple configuration change – just update the Applet Visibility Type in “View Web Template”. This will enforce the specific visibility but is subject to the underlying BusCompView mode available at the underlying Business Component level.

Unfortunately, the same does not hold good for each and every Siebel object at the child level. This is due to Siebel’s way of enforcing visibility. Contacts, Accounts etc. have position-based/org-based visibility rules, while entities like Service Requests and Activities have person-based visibility rules, and other entities like Attachments have no visibility rules whatsoever.

Salesforce has similar visibility rule set to enable visibility at child record level, but is far more powerful than what Siebel can do.

First, you have the visibility rule sets specified at the entity level that is equally applicable to a parent, or a child. Since this is configurable on the fly, this appears to be far easier to develop, test and deploy.

There are rule sets that are specific to the entities (just like in Siebel), and you can easily control distinct visibility rules for employees and external users (e.g. web users, partners etc.).

Next up – you can specify whether each field will be visible and editable (or required) within the entity for defined profiles.

You make it more flexible by enabling the custom sharing rules at the entity level. You can select the records to apply this rule for, and whom the record needs to be shared – either individuals, or arbitrary groups (like User Lists in Siebel).

You can also allow users to control visibility to individual groups and people they choose by turning on the “Manual User Record Sharing” flag. This will add a field to the entities where users can specify the groups/individuals they want to share data with.

Notes and Attachments can also be marked “private”. Similar to “Private” flag in Siebel, this will enable the records to be viewed only by the owner (and administrators). Private Events can be viewed/modified by owners and administrators, and also the roles with “View All Data” or “Modify All Data” permissions.

And, then there is specialized treatment like the “Share With Connections” flag in Attachments. This is a nifty little addition to enable visibility restrictions for attachments that can make individual attachments sharable with the group that has visibility to parent record (like Contact, Account etc.).

Salesforce offers multiple options to share data across the organization, and the flexibility to apply those rules at the child record level provides powerful options for businesses to enable data sharing in a way that works best for their own processes.