How many types of access grants used by Salesforce?
- Explicit grants
- A user or a queue becomes the owner of a record.
- A sharing rule shares the record to a personal or public group, a queue, a role, or a territory.
- An assignment rule shares the record to a user or a queue.
- A territory assignment rule shares the record to a territory.
- A user manually shares the record to a user, a personal or public group, a queue, a role, or a territory.
- A user becomes part of a team for an account, opportunity, or case.
- A programmatic customization shares the record to a user, a personal or public group, a queue, a role, or a territory.
- Group membership grant
- Grants that occur when a user, personal or public group, queue, role, or territory is a member of a group that has explicit access to the record. For example, if a sharing rule explicitly grants the Strategy group access to the Acme record, and Bob is a member of the Strategy group, Bob’s membership in the Strategy group grants him access to the Acme record.
- Inherited grants
- Grants that occur when a user, personal or public group, queue, role, or territory inherits access through a role or territory hierarchy, or is a member of a group that inherits access through a group hierarchy.
- Implicit grants
- Grants that occur when non-configurable record-sharing behaviors built into Salesforce Sales, Service, and Portal applications grant access to certain parent and child records. For example, with this default logic, sometimes referred to as built-in sharing, users can view a parent account record if they have access to its child opportunity, case, or contact record. If those users have access to a parent account record, they can also access its child opportunity, case, and contact records.
a
No, the Share Object does not exist under the following scenarios -
- The object is a detail in a master-detail relationship. In master-detail relationships, the Object Sharing table for the master object controls access to the detail object.
- Both organization-wide default settings (internal and external) are Public Read/Write.
- The object is of a type that doesn’t support Object Sharing tables, such as Activities or Files. These objects have their own access control mechanism.
For users with multiple access grant records in Share Object, what principle does Salesforce use to grant them access to the record?
For users with multiple access grants to a record, Salesforce uses the most permissive grant when determining record access.
Which share access grants are not tracked by Share object?
Sharing granted to users implicitly through organization-wide defaults, the role hierarchy, and permissions such as the “View All” and “Modify All” permissions for the given object, “View All Data,” and “Modify All Data” are not tracked with this object.
How many records can a login history page show?
20,000. To see, login history can download a zipped CSV file.
Field History tracking?
- Number of fields
- Duration of historical data.
- 20 fields OOTB/object (standard or Custom)
- With the Field Audit Trail license, the limit can go up to 60
- The default retention period is 18 months through UI and 24 months by API.
- With the Field Audit Trail license, history retention is possible for 10 Yrs using big objects.
Why Named Credentials is not a good solution for all use cases related to safe guarding application secrets?
Named credentials are best suited for simple authentication schemas such as username and password or OAuth 2.0.
They may not be a best choice as users with
- Modify All Data
- Auther APEX Permissions
can modify or make callouts to the named credentials. They can also access the data protected by the named credential. Or, they might be able to extract the credentials themselves.
If you need to protect against these use cases—for example, you’re an independent software vendor building a package that needs to privately talk to your own cloud services—then consider other options like managed protected custom settings or managed protected custom metadata types
