Wednesday, May 11, 2016

Salesforce Interview Questions-Objects & Fields Part-4

16. Is it possible to change master-detail relationship to lookup relationship?
If the parent object doesn’t have Roll up Summary fields for the child object then we can convert.

17. Is it possible to create the Master – Detail Relationship field for the child object which is having existing records?
No, we cannot create directly. To create first we should create Look up relationship then populate the field value for all the records and then convert the look up relationship to master detail relationship.

18. What will happen if we undelete junction object and normal object from recycle bin?
Master – Detail Relationship data types will be converted to look up relationship data types.
If we undelete any object from recycle bin, then all master detail relationship will be changed to lookup relationship.

19. What will happen if we delete child object in case of look up relationship and master detail relationship?
In case of lookup relationship, we can delete parent object or child object. When parent object will be deleted, the value of lookup relationship field in all child records will become blank.
In case of master-detail relationship, if parent object contain roll up summary, then system will not allow you to delete child object.Also you cannot delete parent object in master detail relationship.

20. Is it possible to filter the records which are coming in look-up window when we click on lookup icon?
Yes, define filter criteria while defining the look up relationship.


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

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