Hot answers tagged

5

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 ...


5

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 ...


4

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 (...


2

After what @Raul said in the comments, and with this known issue, it can be seen that there is a general issue with Salesforce SFDX scratch orgs and "Out of the Box" roles. The workaround I have used is to: pre-define a custom role as part of our meta data called "Automation" execute some Anonymous Apex from our Ant build The Ant script target for point #2 ...


2

Picklists can only be controlled by Record Types but not by Profiles or Roles. If you are using Record types, you can then configure what picklist options are visible for each record type. If you are not using the Record Types, you can use Validation Rules to ensure Users with specific Profile can only select 2 out of the 5 values.


2

The role hierarchy doesn't make sense for all orgs. You might be in one of those situations. Ideally, you might even not use a role at all; Salesforce is quite happy with no users having a role, especially if your organization hierarchy is flat enough that this makes sense. You can also put all users in to a single role, as you propose, which will probably ...


2

Each SObject has a sharing object (for example Account has AccountShare). You can fetch these with the condition ParentID = :accId. Further details here


1

Internal and external Roles will affect the org in the same way. Roles are Roles whether they're internal or external. Regardless of where they're used, the more you use, the slower things will get. I would not make the assumption that 510k is the max, but instead would conclude the max is 500k. Remember you need to provide a Business Use case ...


1

Based on your description, it appears that the "missing" Contact is not associated with an Account. Contacts without Accounts are treated as private: A contact that isn’t linked to an account is always private, regardless of your organization’s sharing model. Only the owner of the contact and administrators can view it. Sharing rules and workflow rules ...


1

You can use authorization as 'Authorization: Bearer <your_session_id>'. You can get session id using UserInfo class httpReq.setHeader('Authorization', 'Bearer ' + UserInfo.getSessionId()); added based on comments As you said SOQL through REST: HttpRequest req = new HttpRequest(); req.setEndpoint('https://ap2.salesforce.com/services/data/v35.0/query/...


1

Your security architecture as described really does not make sense to me. As described, you might as well set the Org-Wide Default to Public, since that seems to be essentially what your sharing rule does. If your users have View All permission on the Case object, you certainly should just change the OWD to Public Read Only. I suspect the real objective is ...


1

You a have to assign the role to adminUser as well. Also, the sequence of steps also needs to be changed. Sequence should be as follows Create adminUser with the role assigned to this user (This role should be other than the customer portal role). Create Account and Contact while running in adminUser context i.e. enclose your Account and Contact creation ...


1

Where in this configuration does this user implicitly gain ownership? If a User has access to a Case record or they own one (irrespective of any record type) and even if they don't own the Account associated to that Case or have any explicit sharing defined for the Account, the User will always have an implicit Read Only access on the Account. This is ...


1

You can refer to this documentation to set up the default number of roles. This has to be increased from communities settings


1

Yes, this is standard behaviour. The reason is that ListView is also an Object and one specific List View is record. If this list view is shared with Role, it will be automatically shared based on princip "Grant Access Using Hierarchies" For list View it is not possible to control if they will be shared using Role hierarchy.


Only top voted, non community-wiki answers of a minimum length are eligible