The primary difference between the two is the question of "how many"?
In the role hierarchy, you are allowed one role as a user. So if I am in a sales hierarchy where it is only regional (East, Central, West, for instance), no problem.
But what if I also have an industry vertical, and I need to be in both East, and the Manufacturing vertical?
This is ...
Here is the documentation that provides the roles specified above that also provides a description. For some reason they are listed in 2 seperate locations but this should cover the list specified in your screenshot.
Enterprise 2.0 Overview - Predefined Roles
Marketing Cloud - SMC Roles
Each Partner Community user associated with the same account gets a unique Role. When a Partner Community user registers from say, Acme Widgets, that user gets the role Acme Widgets User or something of the sort. Every other user who registers related to the Acme Widgets account also gets that role. Users related to other accounts get their own unique role ...
You must specify UserRoleId as null. Reference:
You can insert a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if UserRoleId is specified as null.
The obvious conclusion is that your DataFactory.createUser method is setting the UserRoleId to some other value.
If you must specify this field for ...
You can use the GroupMember object for this. A GroupMember can either be a User or a Group.
Group parentGroup = [Select Id From Group Where Name = 'ParentGroupName'];
Group childGroup = [Select Id From Group Where Name = 'ChildGroupName'];
GroupMember gm = new ...
Roles : Roles control Records
OWD is the foundation which decides whether our data is setup in Private / Public Read Only or Public Read Write. This is the most restrictive data setting.
When the OWD is Private, Sharing Rules become available to open up the OWD data restrictions to groups of users or roles and subordinates. These can either be ownership ...
you can't restrict OWD. OWD is the lowest sharing level.
In this case you have to set OWD to Private and do changes to your sharing model.
you can use the following algorithm to define proper OWD for object
Roles do not restrict anything they only grant you access. Think about a blank profile with nothing checked in object or UI things like API access or being able to email or run reports. You cannot do anything.
As you check more and more options and more and more objects and fields you can see and do more things so a profile gives you access to ...
Yes. Each object has two fields, "sharingModel" and "externalSharingModel". You can import and export these values between orgs. You'll find this setting in the CustomObject metadata. I personally use this method to set up the sharing model for standard and custom objects. There's some weird bugs around it sometimes, so some manual setup may still yet be ...
You will manage the roles in MC. Users still need to be created in Marketing Cloud, and have roles and business units assigned. The advantage of SSO is, that they would not need to provide MC credentials when logging into MC.
You can select which users in SFMC would be applicable for SSO, as you still might have cases where some users (e.g. if you are ...
A user can only have a single Profile and Role assigned to them. The screenshot below shows the Edit User screen where you can set the Profile and Role
Another option to grant permissions to multiple users are Permission Sets. Multiple Permission Sets can be granted to each user
You can also use Public Groups rather than Roles if you want to group users ...
Try using the manual share for the specific opportunity as explained at http://help.salesforce.com/apex/HTViewHelpDoc?id=granting_access_to_records.htm rather than giving him access to opportunities as a whole.
Roles are exposed in the API as UserRole. You could use the DataLoader to run a SOQL query against this sObject and extract all the records to a CSV.
The FuseIT SFDC Explorer has an option to export SOQL query results as CSV.
It can export the SOQL query results as CSV. This will handle paging through all the query results for you.
Disclosure: I work for ...
You can do that by navigating through Setup -> Security Controls -> Sharing Settings, edit the org wide defaults, find your object and change it to private.
More on Organisation Wide Defaults and Sharing
In no particular order...
Time-based workflows with one of these guys as "default running user"?
batch jobs scheduled as one of these guys (Apex will run in system mode and unless the code explicitly checks the permissions - "impossible is nothing").
Integrations? Check the users' login history maybe? Pay attention to IP, login times, the application type.....
The Salesforce PermComparator might be the exact tool you need. You can enter in a user, profile, or permission set and compare it to any other.
Roles are a little bit more difficult, as they don't actually have any permissions directly associated with them, they just control sharing. You're going to need to evaluate the sharing criteria on every object ...
I am assuming you know the Group Id(lets say your group name is MyCoolUsers). If not, you can query on Group object against the developername of the Group.
Next, you need to query on GroupMember object and find out which all groups are part of this Group. Yes, the roles are stored as Groups in GroupMember. Bear with me, I will explain.
SELECT UserOrGroupId ...
Salesforce permissioning and visibility is always additive. You can't subtract visibility using any tools in the security architecture.
These users must have CRUD and FLS to the object to be able to see any record. Then, the next layer is Sharing. If the Org-Wide Default is set to Public Read/Write or Public Read Only, you will need to change it to Private (...
Copy the URL for a record you can see. Send it to another admin, have them open the URL - What Happens? Are you sure when they click on the tab that they are licking "Go" to view the records? (The initial page is a recent items and this trips many people up - Basic I know)
You cannot change field level security by a workflow. However, you could do something like this:
Create a new record type for your object
Create a new page layout (on which you show this specific field) and assign it to the record type
Create a workflow rule based on your criteria + field update that changes the record type
You could create a permission set specifically giving access to those fields, this will allow you to grant access independant of a certain profile.
With a trigger on the User record, you can add the permission set to the user based on the UserRoleId (or query for the role's developername), doing so for the the required role(s).
ROLES in Salesforce are used to govern which RECORDS a user can see, and PROFILES are used for PERMISSIONS (over object types, fields etc.)
It isn't common, or pre-built, to control a specific field access based on a users role. It would be more appropriate to use a different profile and field-level-security (or page layout assignment) to do this.
If you ...
The important part to think about here is License Type. System Administrator is "Salesforce" License type and if you clone the profile and create new profile with SAME License Type of "Salesforce" then they share same set of features and access to objects etc.
I would suggest you to go for a Clone on existing System Administrator profile and create new ...
CEO remains at the top as he is suppose to see all the records across
Now, for longer run, its always better to create geography-wise
roles. So I would suggest creating 4 roles that report to CEO
(North, East, West & South Directors)
Now you can create 4 roles for Sales Associate as of now. (North,
East, West & South Sales Associates ...
Roles are one of the ways you can control access to records in any organization. They also impact reports (e.g. "My Teams" filter). Roles come into play if your security model (OWDs) are set to private. A little more on Roles and how they impact security:
Profiles define how users access objects and data, and what they can do within the application. ...
To help you gain a better understanding, I recommend you read Introducing Role Hierarchies from the Force.com Fundamentals and the sections that follow in the Controlling Access to Records Chapter.
In short, Profiles are about Permissions while Roles are about Records or Sharing Records. Depending on the model you choose to use for record sharing, Roles may ...
I suggest to setup Lead/Contact OWD as private, so that means only the owner of the records or someone higher in the role hierarchy will be able to read them.
Setup > Security Controls > Sharing Settings
Then add sharing rule based criteria, please check the following example where Primary will be your No Mkto Sync
Then select in step 4 to who you want to ...