Salesforce Security in Your Coveo organization

The security of your Salesforce content is maintained in your Coveo organization. When you create a Salesforce source in your Coveo organization, the Salesforce security model is replicated by indexing not only the content but also the permissions associated with all records of objects that you selected to include. This means that with Coveo for Salesforce, when an end user looks at information pulled from Salesforce, they only see what they’re allowed to see in Salesforce.

Bill is a customer support agent in a company. Like his customer support colleagues, in Salesforce, Bill has access to Accounts, Contacts, and Cases, but not to Campaigns, Leads, Opportunities, and Forecasts.

When Bill accesses a Coveo Insight Panel or the Coveo expanded view, the Salesforce results presented only include content from Accounts, Contacts, and Cases. If he was granted access to private objects in Salesforce, content from these records would also be included.

The Coveo organization index replicates the Salesforce security model for:

  • View All permissions

    The Salesforce source fully supports all View All permissions given through a user profile, more explicitly View All Data which applies to every object, View All User which allows a view all on the user object, and View All on specific objects such Accounts, Cases, Leads, and Contact.

    As Salesforce doesn’t support View All Data on ContentVersion, the permission is replicated in your Salesforce source.

  • Sharing permissions

    An administrator can secure private objects with the owner, collaboration group, group, user, bosses of a given user, subordinates of a given user, or Community (also called Network) sharing permission types.

  • Profile associated to the user

    The profile specifies the basic permissions of a user.

    Any user which is granted Read access for an object by his profile is entitled to search for records of the given type.

  • Shared content

    A user can share private content with specific users or groups.

    File sharing settings applied to Chatter files and CRM Content items are also supported. File sharing settings aren’t the same as the sharing settings for private objects.

  • CRM Content

    CRM Content users have access to CRM Content items when they’re entitled to read such items in the library to which the items belong.

  • Chatter

    Chatter posts and comments inherit the permissions of the record onto which they’re posted, no matter if that record is public, private, a group or a user.

    Public and private CollaborationGroups are supported.

  • Communities

    Sharing sets are supported in Communities.

  • Role hierarchy within the organization

    With a role hierarchy, private items are visible by the owner, but also by all parents of the owner in the hierarchy.

  • Permission sets

    Permission sets given to individual users can extend (not restrict) their permissions beyond what’s specified in their profile.

    Any user which is granted Read access for an object by his permission set is entitled to search for records of the given type.

  • License type

    A user license entitles a user to different functionality within Salesforce and determines which profiles and permission sets are available to the user, so your Coveo organization indirectly replicates user license type permissions by indexing permissions from profiles and permission sets.

Coveo organization Salesforce security limitations:

  • Shared personal groups aren’t supported

    A user can share content with a personal group. These sharing permissions can’t be indexed because they’re currently not reported by the Salesforce API. The consequence is that members of the personal group won’t see the shared content in Coveo organization results. This limitation is therefore not a security hole.

  • Field level security isn’t supported

    For Enterprise, Unlimited, and Developer Salesforce editions, visibility of individual fields can be granted or denied to users or groups to fine-tune the access control in a permission set or a profile. The Coveo organization index doesn’t include this information. The consequence is that a user that is denied access to a field could see the content of this field in the Coveo organization results. Note however that this is also the case for Salesforce search results (see the Salesforce item Field-Level Security Overview).

  • Login IP address and hours restrictions aren’t supported

    The Coveo organization index doesn’t contain restrictions on login IP address or hours configured in Salesforce. The consequence is that your Salesforce users can access the Coveo organization search interfaces and review Salesforce content from any IP address at any time.

  • Frozen users aren’t supported

    The user that are frozen using the Freeze button aren’t denied access to the search (see Freezing User Accounts).

  • Knowledge Base (KB) item permissions:

    In Salesforce, you can map User Roles to KB data categories (e.g., members of the Technical Agent role can only see KB articles under the Technical data category). This mapping information isn’t available from the Salesforce API and therefore can’t be indexed. Consequently, in search results, all users can see all KB articles under all data categories.

  • When the organization-wide default is set to Controlled by Parent, a maximum master-detail relationship depth of two levels is supported (see Sharing Default Access Settings).

    When you index a sub-detail object, the detail parents are correctly determined but the master parents are considered public because there are three levels (master-detail-subdetail).

What's Next for Me?