Wednesday, May 11, 2016

Salesforce Interview Questions-Objects & Fields Part-3

11. What is difference between lookup and master details?
Look-up Master
•Up to 25 allowed per object
•Parent is not a required field
•No impact on security and access
•No impact on deletion
•Can be multiple layers deep
• Lookup field is not required
•Up to 2 allowed per objects.
•Parent field on child is required
•Access to parent determines access to children.
•Deleting parent automatically deletes children(cascade delete)
•Can only be multiple layers deep, the number depends on whether master object is a standard or custom object
•Lookup field on page layout is required.

12. What are roll up summary fields?
Rollup-summary fields are supported in master detail relationship. The parent object can use roll-up summary field type to perform operations of sum, maximum, minimum, count among its children records.

13. What is junction object?
Junction object is an object which has master detail relationship with 2 different objects. Many-to-Many relationships are implemented using two master detail objects. One Junction object is used as the child of the objects between which many-to-many relationship needs to be established.

14. What is difference between self-relationship and hierarchical relationship?
Self-relationship is a lookup relationship to itself. For example a case record can be related to parent case record.
When there is self-relationship exist on user object, then it is called hierarchical relationship. For example, an employee's manager is also an employee.

15. Can we change already existing lookup relationship between 2 objects to master detail relationship?
System will allow changing relationship to master-detail only if all child records have value specified for parent as in master detail relationship, master is required.
If any of the child value doesn’t have parent value (means look up field is blank), then system will give validation error while changing the data type.
So if it is required to change relationship, them populate all blank values with some parent value and then change it to master detail.


<<Objects & Fields Part-2                           Objects & Fields Part-4>>

Salesforce Interview Questions-Objects & Fields Part-2

6. What all data type can be used as controlling fields?
Picklist and checkbox. Standard picklist cannot be dependent picklist. Custom fields can be controlling as well as dependent fields.

7. What are encrypted fields?
A field defined as encrypted is not visible to users. Typical usage of encrypted field is for password. Only users with "View Encrypted Data" can view the encrypted fields. Encrypted fields are editable.
Encrypted fields can not be used in where clause in SOQL. To check encrypted fields, Goto Setup > Security Control > PLatform Security > Encryption Policy > Encrypt Fields

8. What is difference between 15 digit and 18 digit Record id?
In Salesforce, whenever user create any component (Object, field, tab etc...) or record then salesforce will generate an unique id with which user can identify the record or component.
After creating the record, in the URL user can see the id of the record which is of 15 digits length.
15 digit id- It is case sensitive and can be seen in user interface in URLs and Reports
18 digit Id- It is case insensitive. APIs and Apex (SOQL) always return 18 digit Id. Even through apex dataloader, we get 18 digit Id.

First 3 digit of record Id specifies the object to which record belongs. For example account records starts with “001” & contact record start with “003”.

9. What are different types of relationship in salesforce?
Basically there are 2 types of relationship, lookup and master detail.
Other relationships are:
  • Self-relationship- When object is related to itself. For example a case can be related to parent case.
  • Hierarchical relationship- When user has relationship with user. For example we can have manager field in user object which is related to user object only.
  • Many to many relationship- When an object is having master detail relationship with 2 different objects.  The intermediate object is called as junction object. An object is called junction object only if it has master detail relationship with 2 different objects.
10. Can a standard object become child in master detail relationship?
No. Standard objects always remain master.


<<Objects & Fields Part-1                      Object & Fields Part-3>>

Salesforce Interview Questions-Objects & Fields Part-1

1. What is difference between standard objects and custom objects?
Standard are objects are predefined by Salesforce like Accounts, Case, Contact etc. Custom object are created by developers based upon application requirements.

2. What are system modifiable fields. Whether these fields can be modified?
Fields like createdby, createddate, modifiedby, modifieddate are system modifiable fields. These fields cann’t be modified. If you want to upload historical data and want to specify values for these fields, then you need to contact salesforce and they will make these fields available for certain duration.
Remember you can specify these fields while doing insert only. You cannot update these fields after insertion. System modifiable fields are available through API’s only not on UI. As a best practice always enable these fields only for initial data migration.

3. True or False: The Created Date can be updated for a record via the API as long as the Modifiable System Fields id turned on.
False. These fields are available for insert and cannot be updated once uploaded.

4. Does salesforce stores the deleted objects and fields?
Yes, salesforce stores the deleted objects and fields for 15 days in recycle bin. You can restore or undelete them from recycle bin.

5. What are external Ids? Does external ids are unique in salesforce?
A field of type external id is a unique id of records from another system. The performance of reports and SOQL is better for fields defined as external ids. Fields of type number, text and email can be set as external id. Each object can have upto three external ids.
External ids are not unique in salesforce. You need select unique and external id checkboxes while creating fields to make external ids unique.
Advantages of External Id:
-Increase report and API SOQL performance
-Used with upsert to easily integrate apps with other systems

                                                                                 

                                                                                  Objects & Fields Part-2>>

Salesforce Interview Questions-Sharing & Security Part-4

16. True or False: A field hidden by field-level security is still visible through the API?
False

17. True or False: Child records in master-detail relationships have their own OWD?
False. In Master detail relationship, child inherit OWD from OWD. If you see OWD for child in master detail relationship, then system will display “Controlled by parent” in OWD settings page.
Child in look up relationship have different OWD as they are loose coupled.

18. If even one person in your organization is not allowed to see position data, what will be OWD ?
Private

19. What is apex manage sharing?
Apex managed sharing is a type of "Programatic Sharing" which allows you to define a custom sharing reason to associate with your programatic share. Standard Salesforce objects support "Programatic Sharing" while custom objects support Apex managed sharing. More specifically, object shares can be written to both standard and custom objects, however custom sharing reasons can only be defined for shares written to custom objects.
apex manage sharing is used for custom objects as we can define apex sharing reason for custom objects. For standard object, apex sharing reason will be “Mannual”.
Salesforce create share table for all objects for which OWD is either public read only or Private. For standard object, share table name is table name followed by share word. For example: AccountShare, ContactShare, CaseShare
For custom object, it is followed by __share. For example : For Position__c, share table name is Position__share

20. How to create share table record using apex?
Share table contains four columns: ParentId, UserOrGroupId, RowCause, AccessLevel.
Below is code to create position__share record:
Position__share p = new Position__share();
p.parentId = ‘Position Record Id which needs to be shared’;
p.userOrGroupId= ‘User id or Group id with which we want to share record’;
p.RowCause=’ apex sharing reason defined for custom object, here for position__c’;
p.AccessLevel =’access level for record’; //can be Read or Edit
insert p;
Note: you cannot update share table record. System only allows insert or delete of records for share table. So if you have to change access for user, you have create new record and can delete already existing record if you want.

21. Can we define apex sharing reason for standard object?
No. We can define apex sharing reasons for custom object.
Apex sharing reasons are defined object by object. - so, positions might have different reasons than candidates.


<<Sharing & Security Part-3


Salesforce Interview Questions-Sharing & Security Part-3

11. What will happen if profile related to user U1 above in role hierarchy doesn’t have CRUD permission for object say A. User U2 below in his role hierarchy have CRUD permission to object A. Will user U1 will be able to see or edit record if Grant Access Using Hierarchies is checked for object A in sharing settings?

No.If a user does not have read or edit access to an object via OWD, a profile or permission set, they will have no visibility over an object regardless of their role and role hierarchy.
Always remember that User above in role hierarchy can see records of users below in hierarchy but operation which he can perform depends on permission on his profile (CRUD & View All & Modify All).

12. What is permission Set?

A permission set is a collection of settings and permissions that give users access to various tools and functions. The settings and permissions in permission sets are also found in profiles, but permission sets extend users’ functional access without changing their profiles.
For example, to give users access to a custom object, create a permission set, enable the required permissions for the object, and assign the permission set to the users. You never have to change profiles, or create a profile for a single use case. While users can have only one profile, they can have multiple permission sets.

13. Is it possible to restrict permission for users using permission set?
No. Permission Set always extends the permission.

14. If you have two record types for an object, do you need to have two page layouts for that objects?
No. It is not required but if user want different UI for different record type then we can create 2 different page layout and assign page layout to profiles based on record type.

15. If a user does not have access to a specific record type, will they be able to see the records that have that record type?
Yes. Record type controls only visibility of record on UI not its access to users.

<<Sharing & Security Part-2         Sharing & Security Part-4>>                              



Tuesday, May 10, 2016

Salesforce Interview Questions-Sharing & Security Part-2


6. When Share button will be available on record detail page?

When OWD for object is “Public Read Only” or “Private”.
If OWD is Public Read-Write, then everyone in org have access to all records of object.

7. How to check whether user has access to a particular record or not?

Query “userRecordAccess” to check whether has access to record or not.
For example:
SELECT RecordId, HasReadAccess, HasTransferAccess, MaxAccessLevel, HasAllAccess, HasDeleteAccess, HasEditAccess FROM UserRecordAccessWHERE UserId = “005xxxxxxxxx”AND RecordId = “001xxxxxxxx”
HasAllAccess Indicates whether a user has all access–read, edit, delete, and transfer—to the record (true) or not (false).
HasReadAccess, HasEditAccess , HasDeleteAccess ,HasTransferAccess return Boolean value.
MaxAccessLevel return access level like None, read, Edit,Delete,Transfer and All.

8. What will happen if a field is hidden through Field level security and user search a values in that field?

Field-level security doesn’t prevent searching on the values in a field. When search terms match on field values protected by field-level security, the associated records are returned in the search results without the protected fields and their values.

9. What does “View all” and “Modify all” permission do at object level?
  • When you grant “View All” or “Modify All” for an object on a profile or permission set, you grant any associated users access to all records of that object regardless of the sharing and security settings.
  • In essence, the “View All” and “Modify All” permissions ignore the sharing model, role hierarchy, and sharing rules that the “Create,” “Read,” “Edit,” and “Delete” permissions respect. Furthermore, “Modify All” also gives a user the ability to mass transfer, mass update, and mass delete records of that specific object, and approve such records even if the user is not a designated approver.
  • These tasks are typically reserved for administrators, but because “View All” and “Modify All” let us selectively override the system, responsibilities that are usually reserved for the administrator can be delegated to other users in a highly controlled fashion.

10. If object-level permissions conflict with record-level permissions, then what will happen?

If object-level permissions conflict with record-level permissions, Salesforce applies the most restrictive settings.
  • If a user’s profile grants him update permission on an object, he will not be able to edit records of that type owned by other users unless read/write record-sharing has been granted.
  • If read/write sharing has been granted, a user whose profile does not specify update permission will not be able to edit records of that type.

<<Sharing & Security Part-1                 Sharing & Security Part-3>>

Salesforce Interview Questions-Sharing & Security Part-1

1. What are different levels of security in salesforce?
  • Object level security
The bluntest way that we can control data is by preventing a user from seeing, creating, editing, and/or deleting any instance of a particular type of object, like a Position or Review. Object-level access allows us to hide whole tabs and objects from particular users, so that they don't even know that type of data exists.
On the platform, we set object-level access rules with object permissions on user profiles.
  • Field level security
A variation on object-level access is field-level access, in which a user can be prevented from seeing, editing, and/or deleting the value for a particular field on an object. Field-level access allows us to hide sensitive information like the maximum salary for a position or a candidate's social security number without having to hide the whole object.
On the platform, we set field-level access rules with the field-level security.
  • Record level security
To control data with a little more finesse, we can allow particular users to view an object, but then restrict the individual object records that they're allowed to see. For example, record-level access allows an interviewer like Melissa Lee to see and edit her own reviews, without exposing the reviews of everyone else on her team.
On the platform, we actually have four ways of setting record-level access rules:
  • Organization-wide defaults
  • Role hierarchies
  • Sharing rules
  • Manual sharing
        
2. What is Organization wide default?

OWD stands for Organization wide defaults. This setting is defined at object level. OWD defined the default record level sharing for objects. All profiles get at least the privileges defined in OWD. OWD takes three different values -
A. Private
B. Public Read only
C. Public Read-Write
To find out what should be set as OWD for an object, first find out which user requires least access to an object. OWD is set based upon this users access requirements.
Most restrictive record access is defined using OWD. Access to additional records is made available through Role hierarchy, Sharing rules, Manual sharing.

3. What is role hierarchy?

Role Hierarchy allows additional users access to records. A hierarchy of roles is defined based upon access requirements at record level. Each user belongs to a unique role. If a role has access to some record, than its parent and ancestors will also have access to this record. Roles can be created using the Manager Users menu. Roles are used to control record access, where as profiles are used to specify access at object and field level.

4. What is public group?

Public group consists of users, roles or "roles and subordinates". Sharing rule is defined using public groups. Record that match certain condition can be assigned to users in public groups using Sharing Rules. Sharing rules functionality is available via the menu Sharing Settings.

5. What is manual sharing (User Managed Sharing)?

Manual Sharing is used to grant one-off access. Manual sharing can be granted by record owner, any one above the owner in role hierarchy and System Administrator. Manual sharing is used to handle exception cases where access to a particular record needs to be given to a specific user. There is a Sharing button on the records page. This is used to provide manual sharing.


<<Objects & Fields Part-1         Sharing & Security Part-2>>