Salesforce Developer Certifications Questions and Answers (Dumps and Practice Questions)

Question : Apex sharing reason can be used for

1. Manual sharing of records or one-off sharing which is done on a record basis
2. General sharing rule
3. Both of above

Correct Answer : 1

Explanation: Apex Sharing Reasons
Apex code can create records in share tables with either a custom RowCause or with a RowCause that is set as "Manual". A "Manual" RowCause means that the share record will be treated as if it was created by User managed sharing. True Apex managed sharing is when a record in a share table has a custom RowCause, which is known as an Apex sharing reason.
Apex sharing reasons are a way for a developer to track why they shared a record with a user or group of users. Using multiple Apex sharing reasons simplifies the coding required to make updates and deletions of sharing records. They also enable developers to share with the same user or group multiple times using different reasons although larger organizations should use caution when doing this since redundant sharing has performance implications.
Each Apex sharing reason has a label and a name. The "label" value is displayed in the "Reason" column when viewing the sharing for a record in the user interface. This allows users and administrators to understand the source of the sharing. The "name" value is used when referencing the reason in the API and Apex.
An example sharing Reason Label might be, "My Sharing Reason". The corresponding Reason Name would be, "My_Sharing_Reason__c".
This Apex sharing reason would be referenced in Apex as follows: Schema.MyCustomObject__Share.rowCause.My_Sharing_Reason__c

Question : 'Status' is a picklist of the Account object having value 'Open' or 'Closed'.
It is possible to create a sharing rule to share only those Accounts whose 'Status' is 'Open'.

1. True
2. False

Correct Answer : 2
Explanation: Criteria-based sharing rules determine whom to share records with based on field values in records. For example, lets say you use a custom object for job applications, with a custom picklist field named Department. You can create a criteria-based sharing rule that shares all job applications in which the Department field is set to IT with all IT managers in your organization.Note

Although criteria-based sharing rules are based on values in the records and not the record owners, a role or territory hierarchy still allows users higher in the hierarchy to access the records.
You cant use Apex to create criteria-based sharing rules. Also, criteria-based sharing cannot be tested using Apex.
You can use the Metadata API to create criteria-based sharing rules starting in API version 24.0.
You cant include high-volume portal users in sharing rules because they dont have roles and cant be in public groups.

Question : Organization wide default (OWD) and sharing rules are applied at the

1. profile level
2. object level
3. record level
4. 1 and 2
5. 2 and 3

Correct Answer : 5

Explanation: Organization-wide sharing settings specify the default level of access to records and can be set separately for accounts (including assets and contracts), activities, contacts, campaigns, cases, leads, opportunities, calendars, price books, and custom objects.

While roles and profiles are used to determine the user-based security, the organization wide default determines the distribution of data with the user. We use the defaults in the object to determine which people across the role hierarchy can access which objects. Objects allowed to be viewed by the organization wide defaults
can be restricted using profiles and roles.

Organization-wide default summarized To set up organization-wide defaults follow the simple method: o First find out which user requires least access to an object. Set the organization-wide default to all the objects based on this user. For example, the library clerk is the person in a library who mostly handles the issuing
and the return of the books. He needs the least access on the customer object (assuming that only the librarian can handle membership) set the customer
object to private read only. o Most restrictive record access is defined using a organization-wide default. Access to additional records is made available through the role hierarchy, sharing rules, and manual sharing. o Changing organization-wide default settings can delete manual sharing if that sharing is no longer needed.

or most objects, organization-wide sharing settings can be set to Private, Public Read Only, or Public Read/Write. In environments where the organization-wide sharing setting for an object is Private or Public Read Only, an administrator can grant users additional access to records by setting up a role hierarchy or defining sharing rules. However, sharing rules can only be used to grant additional access-they cannot be used to restrict access to records beyond what was originally specified with the organization-wide sharing defaults. Important If your organization uses a Customer Portal, before you enable contacts to access the portal, set the organization-wide sharing defaults on accounts, contacts, contracts, assets, and cases to Private. This ensures that by default your customers can view only their own data. You can still grant your Salesforce users Public Read/Write access by creating sharing rules in which all internal users share with all internal users. By default, Salesforce uses hierarchies, like the role or territory hierarchy, to automatically grant access of records to users above the record owner in the hierarchy. Setting an object to Private makes those records visible only to record owners and those above them in the role hierarchy. Use theGrant Access Using Hierarchies checkbox to disable access to records to users above the record owner in the hierarchy for custom objects in Professional, Enterprise, Unlimited, Performance, and Developer Edition. If you deselect this checkbox for a custom object,

Salesforce Developer Certifications Questions and Answers (Dumps and Practice Questions)

Related Questions