141. Time-Dependent Workflow Limitations:
Time triggers don’t support minutes or seconds.
Time triggers can’t reference the following:
• DATE or DATETIME fields containing automatically derived functions, such as TODAY or NOW.
• Formula fields that include related-object merge fields.
You can’t add or remove time triggers if:
• The workflow rule is active.
• The workflow rule is deactivated but has pending actions in the queue.
• The workflow rule evaluation criteria are set to Evaluate the rule when a record is: created, and every time it’s edited.
• The workflow rule is included in a package
.
142. What is Approval Processing?
Approval process is a force.com business logic engine that allows you to specify a sequence of steps that are required to approve a new record. Each step allows one or more designated approvers to accept or reject the record.
143. Approval Terminology
• Approval Request: An approval request is an email notifying the recipient that a record was submitted for approval and his or her approval is requested.
• Approval Steps: Approval steps assign approval requests to various users and define the chain of approval for a particular approval process.
– Each approval step specifies the attributes a record must have to advance to that approval step, the user who can approve requests for those records, and whether to allow the delegate of the approver to approve the requests.
– The first approval step in a process also specifies the action to take if a record does not advance to that step.
– Subsequent steps in the process also allow you to specify what happens if an approver rejects the request.
• Assigned Approver: The assigned approver is the user responsible for approving an approval request.
• Initial Submission Actions: are the actions that occur when a user first submits a record for approval.
– For example, an initial submission action can lock the record so that no users can edit it during the approval process.
– Initial submission actions can also include any approval actions such as assigning a task, sending an email, or updating a field.
• Final Approval Actions: are the actions that occur when all approval requests for a record are approved.
– Final approval actions can include any approval actions such as email alerts, field updates, tasks, or outbound messages.
– For example, a final approval action can change the status to “Approved” and send a notification email.
• Final Rejection Actions: are the actions that occur when all approval requests for a record are rejected.
– Final rejection actions can include any approval actions such as email alerts, field updates, tasks, or outbound messages.
– For example, a final rejection action can change the status to “Rejected”, send a notification email, and unlock the record so that users can edit it before resubmitting.
• Record Locking: is the process of preventing users from editing a record regardless of field-level security or sharing settings.
– Records that are pending approval are automatically locked by Salesforce.
– Users must have the “Modify All Data” permission to edit locked records.
– The Initial Submission Actions, Final Approval Actions, and Final Rejection Actions related lists contain a record lock action that you can edit if necessary
• Outbound Messages: send the information you specify to an endpoint you designate.
– You can set up workflow rules and approval processes to send outbound messages to an endpoint as a means of getting information to an external service.
144. Approval Process Checklist
Use the following checklist to plan your approval process:
– Prepare an Approval Request Email
– Determine the Approval Request Sender
– Determine the Assigned Approver
– Determine the Delegated Approver
– Decide if your approval process needs a filter
– Decide initial submission actions
– Decide if users can approve requests from a wireless device
– Determine if users can edit records that are awaiting approval
– Decide if records should be auto-approved or rejected
– Determine how many levels your process has
– Determine the actions when an approval request is approved or rejected.
145. What is Standard and Custom Fields in Salesforce?
Standard Fields
Standard Fields are pre-defined in Salesforce and you cannot delete standard fields but you can remove non-required standard fields from a page layout
Standard Field customizations include the ability to change standard field labels and tabs
• You can change the display labels of standard tabs, objects, fields, and other related user interface labels so they better reflect your organization’s business requirements.
• Renamed labels – for example, “Accounts” changed to “Companies” – display on all user pages, in Outlook Edition, and in Offline Edition.
• It’s important to note that all pages in the Setup area use the default, original labels.
• Reports and views are not renamed based on the new label value
Custom Fields
Capture information unique to your business process by creating custom fields with custom field help for each of the tabs that your organization uses
Recycle Bin for Deleted Custom Fields
Custom fields are deleted permanently after 45 days
146. Is it possible to change the existing data types of custom fields, if Yes please explain?
Yes. It’s possible but changing the data type of an existing custom field can cause data loss in the following situations:
• Changing to or from type Date or Date/Time
• Changing to Number from any other type
• Changing to Percent from any other type
• Changing to Currency from any other type
• Changing from Checkbox to any other type
• Changing from Picklist (Multi-Select) to any other type
• Changing to Picklist (Multi-Select) from any type except Picklist
• Changing from Auto Number to any other type
• Changing to Auto Number from any type except Text
• Changing from Text Area (Long) to any type except Email, Phone, Text, Text Area, or URL
147. What is a dependent picklist?
Dependent fields can help make your data more accurate and consistent by applying filters.
A dependent field works in conjunction with a controlling field to filter its values. The value chosen in the controlling field affects the values available in the dependent field.
300 is the maximum number of values allowed in a controlling picklist
A custom multi-select picklist cannot be the controlling field for a dependent field
Field Type Controlling Field Dependent Field
Standard Picklist Yes No
Custom Picklist Yes Yes
Custom Multi-Select No Yes
Standard Checkbox Yes No
Custom Checkbox Yes No
148. What is a Business Process?
Business process allows you to track separate sales, support, and lead lifecycles across different divisions, groups, or markets.
Available Business Processes:
Sales Processes – Create different sales processes that include some or all of the picklist values available for the Opportunity Stage field
Support Processes – Create different support processes that include some or all of the picklist values available for the Case Status field
Lead Processes – Create different lead processes that include some or all of the picklist values available for the Lead Status field
Solution Processes – Create different solution processes that include some or all of the picklist values available for the Solution Status field
149. What is Web-to-Lead and Web-to-Case? (More explanation needed)
A lead or case record created through Web-to-Lead or Web-to-Case will set the record type to that of the default lead owner or automated case user (optional)
150. On which tabs can I create multiple record types?
Multiple record types may be created for every tab, with the exception of the Home, Forecasts, Documents, and Reports tabs.
151. What happens if I try to add new picklist value?
You will be prompted to select which record types should include the new value
152. Why use Field-Level Security?
Use Field-Level Security (rather than creating multiple page layouts) to enforce data security
Users view data relevant to their job function Troubleshooting Tools Field accessibility views
Setup | Administration Setup | Security Controls | Field Accessibility
Notes:
• Field Level Security is not available in PE
• Field-level security cannot be used to make a field required. This is done from the Page Layout
• Field access settings can be defined using both field-level security and page layouts. However, the most restrictive field access setting of the two will always apply.
For example, if a field is required on the page layout, but read-only in the field-level security settings, the field will be read-only.
• Hiding a field from a user using FLS also hides that field from list views, search results, and reports.
153. What are Login Hours and Login IP Ranges?
Login hour sets the hours when users with a particular profile can use the system
Login IP Ranges sets the IP addresses from which users with a particular profile can log in
Notes:
• You can customize profiles to restrict users’ ability to log in to Salesforce.
• You can set the hours when users can log in and the IP addresses from which they can log in.
If a user logs in before the restricted hours, the system will end the user’s session when the restricted hours begin.
Two Options for Restricting Access via IP Ranges
Option 1: Add Trusted IP Ranges for your entire org
Option 2: Add Trusted IP Ranges on a Profile by Profile basis
154. What is a User Record?
User record possesses key information about a user and each has its own unique username.
Other properties of User records are below
• User logs in with username and password
• Users can be active or inactive; an active user uses a license
• Users are associated with a Profile
• Users are usually associated with a Role
155. What is a Record Owner?
Record owner is he user (or queue for Cases and Leads) who controls or has rights to that particular data record.
An Owner has the following special privileges with the below assumptions:
• View and edit capabilities
• Transfer capability – change ownership
• Deletion capabilities
Important assumption:
Object permissions enabled
The Account Owner, Opportunity Owners and Case Owners may or may not be the same user.
156. What are Organization Wide Defaults?
OWD Defines the baseline level of access to data records for all users in the Organization (not including records owned by the user or inherited via role hierarchy) Used to restrict access to data Access levels to
Private
Public Read/Write
Public Read/Write/Transfer
Public Full Access
Public Read Only
157. What is a Role and Role Hierarchy?
Role:
Controls the level of visibility that users have to an organization’s data
An user may be associated to one role
Role Hierarchy:
Controls data visibility
Controls record roll up – forecasting and reporting
Users inherit the special privileges of data owned by or shared with users below them in the hierarchy
Not necessarily the company’s organization chart
Notes:
• If using Customizable Forecasting, there is a separate forecast role hierarchy.
• EE can create Account, Contact, Opportunity and Case Sharing Rules. PE can ONLY create Account and Contact Sharing Rules.
• Assuming no sharing rules have been created, users in the same role cannot access one another’s records.
Example: Org Wide Default settings for opportunities are private. Creating a role and adding two users to that role does not allow those users access to one another’s opportunities.
• “Grant Access Using Hierarchies” allows you to disable the default sharing access granted by your role and territory hierarchies. This option can be changed for custom objects that do not have their organization-wide default sharing setting set to Controlled by Parent.
158. What is Access at the Role Level?
Access is defined when creating a role
Level of access to Opportunities associated to Accounts owned by the role
Level of access to Contacts associated to Accounts owned by the Role
Level of access to Cases associated to Accounts owned by the role
Level of access options depend on OWD
Notes:
• You can create up to 500 roles for your organization
• Every user must be assigned to a role, or their data will not display in opportunity reports, forecast roll-ups, and other displays based on roles
• All users that require visibility to the entire organization should belong to the highest level in the hierarchy
• It is not necessary to create individual roles for each title at your company, rather you want to define a hierarchy of roles to control access of information entered by users in lower level roles
• When you change a user’s role, any relevant sharing rules are evaluated to add or remove access as necessary
159. What is a Sharing Rule?
Sharing rules are automated rules that grant access to groups of users
These are exceptions to Organization Wide Defaults
Irrelevant for Public Read/Write organizations
Levels of Access that can be granted are
• Read Only
• Read/Write
Notes:
• Sharing rules should be used when a user or group of users needs access to records not granted them by either the role hierarchy setup or the organization wide default settings.
• Sharing rules open up access whereas organization wide defaults restrict access.
• You can use sharing rules to grant wider access to data. You cannot restrict access below your organization-wide default levels.
• Sharing rules apply to all new and existing records owned by the specified role or group members.
• Sharing rules apply to both active and inactive users.
• When you change the access levels for a sharing rule, all existing records are automatically updated to reflect the new access levels.
• When you delete a sharing rule, the sharing access created by that rule is automatically removed.
• When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as necessary.
• When you modify which users are in a group or role, the sharing rules are reevaluated to add or remove access as necessary.
• For contact, opportunity and case sharing rules, if the role or group members do not have access to the account associated with the shared contact, opportunity or case the rule automatically gives them access to view the account as well.
• Managers in the role hierarchy are automatically granted the same access that users below them in the hierarchy have from a sharing rule.
• You can edit the access levels for any sharing rule. You cannot change the specified groups or roles for the rule.
160. What are the types of Sharing Rules in Salesforce and explain them?
Sharing rules present in salesforce are as below.
Account Sharing Rules:
• Based on who owns the account
• Set default sharing access for accounts and their associated cases, contacts, contracts, and opportunities
Contact Sharing Rules:
• Based on who owns the contact (must be associated with an account)
• Set default sharing access for individual contacts and their associated accounts
• Cannot use with: Territory Management and B2I (Person Account) enabled orgs
Opportunity Sharing Rules (EE/UE):
• Based on who owns the opportunity
• Set default sharing access for individual opportunities and their associated accounts
Case Sharing Rules (EE/UE):
• Based on who owns the case
• Set default sharing access for individual cases and associated accounts
Lead Sharing Rules (EE/UE):
• Based on who owns the lead
• Set default sharing access for individual leads
Custom Object Sharing Rules (EE/UE):
• Based on who owns the custom object
• Set default sharing access for individual custom object records
Time triggers don’t support minutes or seconds.
Time triggers can’t reference the following:
• DATE or DATETIME fields containing automatically derived functions, such as TODAY or NOW.
• Formula fields that include related-object merge fields.
You can’t add or remove time triggers if:
• The workflow rule is active.
• The workflow rule is deactivated but has pending actions in the queue.
• The workflow rule evaluation criteria are set to Evaluate the rule when a record is: created, and every time it’s edited.
• The workflow rule is included in a package
.
142. What is Approval Processing?
Approval process is a force.com business logic engine that allows you to specify a sequence of steps that are required to approve a new record. Each step allows one or more designated approvers to accept or reject the record.
143. Approval Terminology
• Approval Request: An approval request is an email notifying the recipient that a record was submitted for approval and his or her approval is requested.
• Approval Steps: Approval steps assign approval requests to various users and define the chain of approval for a particular approval process.
– Each approval step specifies the attributes a record must have to advance to that approval step, the user who can approve requests for those records, and whether to allow the delegate of the approver to approve the requests.
– The first approval step in a process also specifies the action to take if a record does not advance to that step.
– Subsequent steps in the process also allow you to specify what happens if an approver rejects the request.
• Assigned Approver: The assigned approver is the user responsible for approving an approval request.
• Initial Submission Actions: are the actions that occur when a user first submits a record for approval.
– For example, an initial submission action can lock the record so that no users can edit it during the approval process.
– Initial submission actions can also include any approval actions such as assigning a task, sending an email, or updating a field.
• Final Approval Actions: are the actions that occur when all approval requests for a record are approved.
– Final approval actions can include any approval actions such as email alerts, field updates, tasks, or outbound messages.
– For example, a final approval action can change the status to “Approved” and send a notification email.
• Final Rejection Actions: are the actions that occur when all approval requests for a record are rejected.
– Final rejection actions can include any approval actions such as email alerts, field updates, tasks, or outbound messages.
– For example, a final rejection action can change the status to “Rejected”, send a notification email, and unlock the record so that users can edit it before resubmitting.
• Record Locking: is the process of preventing users from editing a record regardless of field-level security or sharing settings.
– Records that are pending approval are automatically locked by Salesforce.
– Users must have the “Modify All Data” permission to edit locked records.
– The Initial Submission Actions, Final Approval Actions, and Final Rejection Actions related lists contain a record lock action that you can edit if necessary
• Outbound Messages: send the information you specify to an endpoint you designate.
– You can set up workflow rules and approval processes to send outbound messages to an endpoint as a means of getting information to an external service.
144. Approval Process Checklist
Use the following checklist to plan your approval process:
– Prepare an Approval Request Email
– Determine the Approval Request Sender
– Determine the Assigned Approver
– Determine the Delegated Approver
– Decide if your approval process needs a filter
– Decide initial submission actions
– Decide if users can approve requests from a wireless device
– Determine if users can edit records that are awaiting approval
– Decide if records should be auto-approved or rejected
– Determine how many levels your process has
– Determine the actions when an approval request is approved or rejected.
145. What is Standard and Custom Fields in Salesforce?
Standard Fields
Standard Fields are pre-defined in Salesforce and you cannot delete standard fields but you can remove non-required standard fields from a page layout
Standard Field customizations include the ability to change standard field labels and tabs
• You can change the display labels of standard tabs, objects, fields, and other related user interface labels so they better reflect your organization’s business requirements.
• Renamed labels – for example, “Accounts” changed to “Companies” – display on all user pages, in Outlook Edition, and in Offline Edition.
• It’s important to note that all pages in the Setup area use the default, original labels.
• Reports and views are not renamed based on the new label value
Custom Fields
Capture information unique to your business process by creating custom fields with custom field help for each of the tabs that your organization uses
Recycle Bin for Deleted Custom Fields
Custom fields are deleted permanently after 45 days
146. Is it possible to change the existing data types of custom fields, if Yes please explain?
Yes. It’s possible but changing the data type of an existing custom field can cause data loss in the following situations:
• Changing to or from type Date or Date/Time
• Changing to Number from any other type
• Changing to Percent from any other type
• Changing to Currency from any other type
• Changing from Checkbox to any other type
• Changing from Picklist (Multi-Select) to any other type
• Changing to Picklist (Multi-Select) from any type except Picklist
• Changing from Auto Number to any other type
• Changing to Auto Number from any type except Text
• Changing from Text Area (Long) to any type except Email, Phone, Text, Text Area, or URL
147. What is a dependent picklist?
Dependent fields can help make your data more accurate and consistent by applying filters.
A dependent field works in conjunction with a controlling field to filter its values. The value chosen in the controlling field affects the values available in the dependent field.
300 is the maximum number of values allowed in a controlling picklist
A custom multi-select picklist cannot be the controlling field for a dependent field
Field Type Controlling Field Dependent Field
Standard Picklist Yes No
Custom Picklist Yes Yes
Custom Multi-Select No Yes
Standard Checkbox Yes No
Custom Checkbox Yes No
148. What is a Business Process?
Business process allows you to track separate sales, support, and lead lifecycles across different divisions, groups, or markets.
Available Business Processes:
Sales Processes – Create different sales processes that include some or all of the picklist values available for the Opportunity Stage field
Support Processes – Create different support processes that include some or all of the picklist values available for the Case Status field
Lead Processes – Create different lead processes that include some or all of the picklist values available for the Lead Status field
Solution Processes – Create different solution processes that include some or all of the picklist values available for the Solution Status field
149. What is Web-to-Lead and Web-to-Case? (More explanation needed)
A lead or case record created through Web-to-Lead or Web-to-Case will set the record type to that of the default lead owner or automated case user (optional)
150. On which tabs can I create multiple record types?
Multiple record types may be created for every tab, with the exception of the Home, Forecasts, Documents, and Reports tabs.
151. What happens if I try to add new picklist value?
You will be prompted to select which record types should include the new value
152. Why use Field-Level Security?
Use Field-Level Security (rather than creating multiple page layouts) to enforce data security
Users view data relevant to their job function Troubleshooting Tools Field accessibility views
Setup | Administration Setup | Security Controls | Field Accessibility
Notes:
• Field Level Security is not available in PE
• Field-level security cannot be used to make a field required. This is done from the Page Layout
• Field access settings can be defined using both field-level security and page layouts. However, the most restrictive field access setting of the two will always apply.
For example, if a field is required on the page layout, but read-only in the field-level security settings, the field will be read-only.
• Hiding a field from a user using FLS also hides that field from list views, search results, and reports.
153. What are Login Hours and Login IP Ranges?
Login hour sets the hours when users with a particular profile can use the system
Login IP Ranges sets the IP addresses from which users with a particular profile can log in
Notes:
• You can customize profiles to restrict users’ ability to log in to Salesforce.
• You can set the hours when users can log in and the IP addresses from which they can log in.
If a user logs in before the restricted hours, the system will end the user’s session when the restricted hours begin.
Two Options for Restricting Access via IP Ranges
Option 1: Add Trusted IP Ranges for your entire org
Option 2: Add Trusted IP Ranges on a Profile by Profile basis
154. What is a User Record?
User record possesses key information about a user and each has its own unique username.
Other properties of User records are below
• User logs in with username and password
• Users can be active or inactive; an active user uses a license
• Users are associated with a Profile
• Users are usually associated with a Role
155. What is a Record Owner?
Record owner is he user (or queue for Cases and Leads) who controls or has rights to that particular data record.
An Owner has the following special privileges with the below assumptions:
• View and edit capabilities
• Transfer capability – change ownership
• Deletion capabilities
Important assumption:
Object permissions enabled
The Account Owner, Opportunity Owners and Case Owners may or may not be the same user.
156. What are Organization Wide Defaults?
OWD Defines the baseline level of access to data records for all users in the Organization (not including records owned by the user or inherited via role hierarchy) Used to restrict access to data Access levels to
Private
Public Read/Write
Public Read/Write/Transfer
Public Full Access
Public Read Only
157. What is a Role and Role Hierarchy?
Role:
Controls the level of visibility that users have to an organization’s data
An user may be associated to one role
Role Hierarchy:
Controls data visibility
Controls record roll up – forecasting and reporting
Users inherit the special privileges of data owned by or shared with users below them in the hierarchy
Not necessarily the company’s organization chart
Notes:
• If using Customizable Forecasting, there is a separate forecast role hierarchy.
• EE can create Account, Contact, Opportunity and Case Sharing Rules. PE can ONLY create Account and Contact Sharing Rules.
• Assuming no sharing rules have been created, users in the same role cannot access one another’s records.
Example: Org Wide Default settings for opportunities are private. Creating a role and adding two users to that role does not allow those users access to one another’s opportunities.
• “Grant Access Using Hierarchies” allows you to disable the default sharing access granted by your role and territory hierarchies. This option can be changed for custom objects that do not have their organization-wide default sharing setting set to Controlled by Parent.
158. What is Access at the Role Level?
Access is defined when creating a role
Level of access to Opportunities associated to Accounts owned by the role
Level of access to Contacts associated to Accounts owned by the Role
Level of access to Cases associated to Accounts owned by the role
Level of access options depend on OWD
Notes:
• You can create up to 500 roles for your organization
• Every user must be assigned to a role, or their data will not display in opportunity reports, forecast roll-ups, and other displays based on roles
• All users that require visibility to the entire organization should belong to the highest level in the hierarchy
• It is not necessary to create individual roles for each title at your company, rather you want to define a hierarchy of roles to control access of information entered by users in lower level roles
• When you change a user’s role, any relevant sharing rules are evaluated to add or remove access as necessary
159. What is a Sharing Rule?
Sharing rules are automated rules that grant access to groups of users
These are exceptions to Organization Wide Defaults
Irrelevant for Public Read/Write organizations
Levels of Access that can be granted are
• Read Only
• Read/Write
Notes:
• Sharing rules should be used when a user or group of users needs access to records not granted them by either the role hierarchy setup or the organization wide default settings.
• Sharing rules open up access whereas organization wide defaults restrict access.
• You can use sharing rules to grant wider access to data. You cannot restrict access below your organization-wide default levels.
• Sharing rules apply to all new and existing records owned by the specified role or group members.
• Sharing rules apply to both active and inactive users.
• When you change the access levels for a sharing rule, all existing records are automatically updated to reflect the new access levels.
• When you delete a sharing rule, the sharing access created by that rule is automatically removed.
• When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as necessary.
• When you modify which users are in a group or role, the sharing rules are reevaluated to add or remove access as necessary.
• For contact, opportunity and case sharing rules, if the role or group members do not have access to the account associated with the shared contact, opportunity or case the rule automatically gives them access to view the account as well.
• Managers in the role hierarchy are automatically granted the same access that users below them in the hierarchy have from a sharing rule.
• You can edit the access levels for any sharing rule. You cannot change the specified groups or roles for the rule.
160. What are the types of Sharing Rules in Salesforce and explain them?
Sharing rules present in salesforce are as below.
Account Sharing Rules:
• Based on who owns the account
• Set default sharing access for accounts and their associated cases, contacts, contracts, and opportunities
Contact Sharing Rules:
• Based on who owns the contact (must be associated with an account)
• Set default sharing access for individual contacts and their associated accounts
• Cannot use with: Territory Management and B2I (Person Account) enabled orgs
Opportunity Sharing Rules (EE/UE):
• Based on who owns the opportunity
• Set default sharing access for individual opportunities and their associated accounts
Case Sharing Rules (EE/UE):
• Based on who owns the case
• Set default sharing access for individual cases and associated accounts
Lead Sharing Rules (EE/UE):
• Based on who owns the lead
• Set default sharing access for individual leads
Custom Object Sharing Rules (EE/UE):
• Based on who owns the custom object
• Set default sharing access for individual custom object records
