Activity Forums Salesforce® Discussions How to protect contact information from being seen by the marketing team?

  • How to protect contact information from being seen by the marketing team?

  • Parul

    August 20, 2018 at 7:12 am

    How can an App Builder protect contact information from being seen by the marketing team when that contact is added to a campaign?

    • This discussion was modified 3 years, 2 months ago by  Parul.
    • This discussion was modified 3 years, 1 month ago by  Forcetalks.
    • This discussion was modified 3 years, 1 month ago by  Forcetalks.
  • Anjali

    August 20, 2018 at 7:40 am

    Hi Parul,

    By setting campaign member sharing settings. To let your marketing department see only the campaign member details that you want them to. Sharing rules for campaign members can inherit from lead and contact rules or from the campaign.

    To let users see only the campaign members whose lead or contact records they have access to, choose Controlled by Lead or Contact in Sharing Settings. To let users who have access to a campaign see campaign member details, choose Controlled by Campaign. Access that’s provided by a user’s role or profile supersedes the organization-wide defaults.

  • shariq

    September 16, 2018 at 12:51 pm


    To get it more simple -

    Salesforce provides a flexible, layered data sharing design that allows you to expose different data sets to different sets of users, so users can do their job without seeing data they don't need to see. Use permission sets and profiles to specify the objects and fields users can access. Use organization-wide sharing settings, user roles, sharing rules to specify the individual records that users can view and edit.

    Object-Level Security (Permission Sets and Profiles)

    Object-level security—or object permissions—provide the bluntest way to control data. Using object permissions you can prevent a user from seeing, creating, editing, or deleting any instance of a particular type of object, such as a lead or opportunity. Object permissions let you hide whole tabs and objects from particular users, so that they don’t even know that type of data exists.You specify object permissions in permission sets and profiles. Permission sets and profiles are collections of settings and permissions that determine what a user can do in the application, similar to a group in a Windows network, where all of the members of the group have the same folder permissions and access to the same software.Profiles are typically defined by a user’s job function (for example, system administrator or sales representative). A profile can be assigned to many users, but a user can be assigned to only one profile. You can use permission sets to grant additional permissions and access settings to users. It’s easy to manage users’ permissions and access with permission sets, because you can assign multiple permission sets to a single user.

    Field-Level Security (Permission Sets and Profiles)

    In some cases, you may want users to have access to an object, but limit their access to individual fields in that object. Field-level security—or field permissions—control whether a user can see, edit, and delete the value for a particular field on an object. They let you protect sensitive fields without having to hide the whole object from users. Field permissions are also controlled in permission sets and profiles.Unlike page layouts, which only control the visibility of fields on detail and edit pages, field permissions control the visibility of fields in any part of the app, including related lists, list views, reports, and search results. To ensure that a user can’t access a particular field, use field permissions. No other settings provide the same level of protection for a field.

    Record-Level Security (Sharing)

    After setting object- and field-level access permissions, you may want to configure access settings for the actual records themselves. Record-level security lets you give users access to some object records, but not others. Every record is owned by a user or a queue. The owner has full access to the record. In a hierarchy, users higher in the hierarchy always have the same access to users below them in the hierarchy. This access applies to records owned by users, as well as records shared with them.To specify record-level security, set your organization-wide sharing settings, define a hierarchy, and create sharing rules.

    • Organization-wide sharing settings—The first step in record-level security is to determine the organization-wide sharing settings for each object. Organization-wide sharing settings specify the default level of access users have to each others’ records.You use organization-wide sharing settings to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools to selectively give access to other users. For example, let’s say users have object-level permissions to read and edit opportunities, and the organization-wide sharing setting is Read-Only. By default, those users can read all opportunity records, but can’t edit any unless they own the record or are granted additional permissions.


    • Role hierarchy—Once you’ve specified organization-wide sharing settings, the first way you can give wider access to records is with a role hierarchy. Similar to an organization chart, a role hierarchy represents a level of data access that a user or group of users needs. The role hierarchy ensures that users higher in the hierarchy always have access to the same data as people lower in their hierarchy, regardless of the organization-wide default settings. Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.You can also use a territory hierarchy to share access to records. A territory hierarchy grants users access to records based on criteria such as zip code, industry, revenue, or a custom field that is relevant to your business. For example, you could create a territory hierarchy in which a user with the “North America” role has access to different data than users with the “Canada” and “United States” roles.
    • Sharing rules—Sharing rules let you make automatic exceptions to organization-wide sharing settings for particular sets of users, to give them access to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records—they can’t be stricter than your organization-wide default settings.
    • Manual sharing—Sometimes it’s impossible to define a consistent group of users who need access to a particular set of records. In those situations, record owners can use manual sharing to give read and edit permissions to users who would not have access to the record any other way. Although manual sharing isn’t automated like organization-wide sharing settings, role hierarchies, or sharing rules, it gives record owners the flexibility to share particular records with users that need to see them.
    • Apex managed sharing—If sharing rules and manual sharing don’t give you the control you need, you can use Apex managed sharing. Apex managed sharing allows developers to programmatically share custom objects. When you use Apex managed sharing to share a custom object, only users with the “Modify All Data” permission can add or change the sharing on the custom object's record, and the sharing access is maintained across record owner changes.

    Hope this helps.

Viewing 1 - 3 of 3 posts

Log In to reply.

Popular Salesforce Blogs

Popular Salesforce Videos