127. What are the important points to know about encrypted fields?
Answer :
- User profiles who have the “View Encrypted Data” configuration enabled will be able to view the field normally.
- Users who do not have the “View Encrypted Data” profile will see the mask.
- User profiles that have the “Modify All Data” permission will not be able to see the value of encrypted data fields.
- The field length is restricted to 175 characters in size.
- Encrypted Field cannot be type cast as Unique or External ID.
- An encrypted field cannot be configured with a default value.
- You can’t use encrypted fields in report filters and list views.
- You can’t use the encrypted fields in SOQL “where/order” clauses.
- Also we can not use encrypted field formula fields, workflow rules, workflow field updates, approval process entry criteria, and approval step criteria.
- If you clone a record that has encrypted custom fields, Salesforce will copy the data from the field ONLY if the user has the “view encrypted data” permission.
- You can access the data of encrypted field in apex, i.e value is always unmasked.
128. Can we disable Apex Triggers in Salesforce production?
Answer:
Triggers are not editable once deployed,
But we can deactivate this using alternate solution which is Using Force.Com IDE / Change Sets, Inactive/Disable the trigger and then deploy apex trigger into the Salesforce production.
But I prefer to use above solution when you need to stop trigger logic in URGENT basis.
then Big Question, Is there any other solution without deployment?
Yes, It's design solution :
1. Create configuration [Custom Setting / Custom Metadata Type] to maintain the flag for each trigger execution.
( Tip: Use Custom Metadata Types for App Configuration )
If you're thinking of using list custom settings, consider using custom metadata types instead. Unlike list custom settings, you can migrate the records of custom metadata types using packages or Metadata API tools. You can enable List Custom Settings on the Schema Settings page in Setup.
2. With the help of the above configuration, Execute the trigger logic.
129. Which are the possible ways to search within Salesforce?
Answer:
- Global Search
- Advanced Search
- Sidebar Search
- Lookup Search
130. In which below scenario users will be able to edit each other's records?
Profile
OWD
Able to Edit
Read-only
Read and Write
Yes/No?
Read and Write
Private
Yes/No?
Answer:
In either of scenario, the answer is "NO", because Profile is Object level permission and OWN is Record level permission.
Profile - Object level permission
OWD - Record level permission
128. Can we disable Apex Triggers in Salesforce production?
Answer:
Triggers are not editable once deployed,
But we can deactivate this using alternate solution which is Using Force.Com IDE / Change Sets, Inactive/Disable the trigger and then deploy apex trigger into the Salesforce production.
But I prefer to use above solution when you need to stop trigger logic in URGENT basis.
then Big Question, Is there any other solution without deployment?
Yes, It's design solution :
1. Create configuration [Custom Setting / Custom Metadata Type] to maintain the flag for each trigger execution.
( Tip: Use Custom Metadata Types for App Configuration )
If you're thinking of using list custom settings, consider using custom metadata types instead. Unlike list custom settings, you can migrate the records of custom metadata types using packages or Metadata API tools. You can enable List Custom Settings on the Schema Settings page in Setup.
2. With the help of the above configuration, Execute the trigger logic.
129. Which are the possible ways to search within Salesforce?
Answer:
- Global Search
- Advanced Search
- Sidebar Search
- Lookup Search
130. In which below scenario users will be able to edit each other's records?
Profile
|
OWD
|
Able to Edit
|
Read-only
|
Read and Write
|
Yes/No?
|
Read and Write
|
Private
|
Yes/No?
|
Answer:
In either of scenario, the answer is "NO", because Profile is Object level permission and OWN is Record level permission.
Profile - Object level permission
OWD - Record level permission
131. If the Workflow field update & Trigger on the same set of attribute and action, Will it fall under infinite loop?
Answer:
Not actually, If the record was updated with workflow field updates, fires before and after triggers events one more time (and only one more time),
And as per Order of Execution in Salesforces in 15 Easy Steps, standard validations, and Custom validation rules are not run again.
132. Give me different ways to invoke an apex call out from Queueable class?
Answer:
- Implement the "Database.AllowCallouts" interface along with the "Queueable" interface to enable the call outs.
- Create a future method with call out operation & Call the future method in Queueable execute method
- Create a public static function that performs a call out and call that from Queueable execute method.
133. What is the significance of Geo fields on an object?
Answer:
To create Geo fields there is a datatype "Geolocation", Which allows users to define locations.
Includes latitude and longitude components and can be used to calculate distance.
134. When is best to use Profiles instead of Permission Sets?
Answer:
134. When is best to use Profiles instead of Permission Sets?
Answer:
Profile for core level & Permission Sets used to give extended permissions.
Profiles: Set access to Tabs, Apps, record types, Page layout assignment etc
Permission Set: To give access to only certain user in the profile
Note: Permission sets can only grant access, But cannot restrict any access.
To answer to the question, Profiles are best to control Field Level security.
135: Is it possible to achieve Many to Many relationship by using lookup relationships?
Answer:
To answer the question ,Yes it is possible.
Junction Object: This is a custom object with 2 Master - Detail relationships is the key to making Many to Many relationship.
Note: The downside is, Junction object will not be automatically deleted when one or both of the objects it is relating are deleted.
No comments:
Post a Comment