ADM 211: Sales Cloud Applications

Territory Management: A territory is a flexible collection of accounts and users where the users have at least read access to accounts, regardless of who owns the acocunt. 1. Not enabled by default 2. Only available with Customizable Forecasts 3. A user can be part of multiple territories 4. An account can belong to multiple territories 5. Accounts are accessible to all users in the assigned territory as well as those above them in the territory hierarchy A territory hierarchy is what you can set up to create nested levels. For example: a top level territory might be “Whole United States” that includes child levels of “Northwest, Northeast, Southwest and South East”. More information on Territory Management When you enable territory management for you organization your territory hierarchy becomes your forecast hierarchy. Customizable Forecasting   With Customizable forecasting, you can forecast on a monthly or quarterly basis, use different dates when applying amounts to forecasts, forecast based on revenue or quantity or both, and define additional quotas based on product families. The categories below are available to help drill down further into the data: Best Case: includes amounts you are likely to close, closed/won opportunity amounts, and amounts in the Commit category. Closed: includes amounts for closed/won opportunities. Commit: includes amounts you are confident about closing and closed/won opportunity amounts. Omitted: means the amount does not contribute to your forecast. Pipeline: includes amounts from all open opportunities.   These can be updated to fit the business process Each value in the opportunity Stage picklist is automatically mapped to a Probability and value in the Forecast Categorypicklist. Change the Stage of an opportunity and the Probability as well as the Forecast Category changes with it. For example,...

ADM 211: Auditing and Monitoring

New Concepts Delegated Administration Delegated administration is useful when you want to allow a user to have administrative privileges for only a subset of your organization. A delegated administrator may: Create and edit users in specified roles and all subordinate roles. For these users a delegated admin may reset passwords, set quotas, create default opportunity teams, and creating personal groups for these users. Unlock Users Assign users to specified profiles and permission sets Create public groups and manage membership in specified public groups Log in as users who have granted login access to their administrator Manage custom objects When delegated administrators are assigned to multiple delegated groups, they can administer users across all of those delegated groups. To delegate administration for a particular object, use object permissions, such as “View All” and “Modify All”. Login History As an administrator you are able to monitor all login attempts for the organization, enabled portals and/or communities. In order to view view these files the “Manage Users” permission is needed. When reviewing the login history the following are available: 1. Username 2. Login Time 3. Source IP 4. Location 5. Login Type 6. Status 7. Browser 8. Platform 9. Application 10. Client Version 11. API Type 12. Login URL   Debug Log A debug log is used to record database operations, system processes, and errors that occur when executing a transaction or running unit tests. A debug log may contain the following: • Database changes • HTTP callouts • Apex errors • Resources used by Apex • Automated workflow processes, such as: • Workflow rules • Assignment rules • Approval processes • Validation rules...

ADM 211: Extending Custom Objects and Applications

Review Converting Relationships You can convert a master-detail relationship to a lookup relationship as long as no roll-up summary fields exist on the master object. You can convert a lookup relationship to a master-detail relationship, but only if the lookup field in all records contains a value. Relationship Limits Each custom object can have up to two master-detail relationships and many lookup relationships. Each relationship is included in the maximum number of custom fields allowed. Relationships on External Objects Lookup, external lookup, and indirect lookup relationships have some special behaviors and limitations. • Only lookup, external lookup, and indirect lookup relationships are available for external objects. No other relationship types are supported. • Indirect lookup relationship fields can be created on external objects only. • Depending on the availability of the external system, related lists of child external objects may load slowly when users view the parent record detail pages. • With external lookup and indirect lookup relationships, the parent record appears as a clickable link in the relationship field on the child record. If the child record is viewed by a user who doesn’t have access to the parent record, the parent record appears in the relationship field as plain text instead of a link. • Only objects that have a custom field with the External ID and Unique attributes are available as parent objects in indirect lookup relationships. If you don’t see the desired object when you create an indirect lookup relationship field, add a custom unique, external ID field to that object. • Lookup filters aren’t available for external lookup relationship fields. • Cascade-delete isn’t available for external object relationships.    ...

ADM 211: Security and Access

Review Organization Wide Defaults Organization Wide defaults allow you to specify the default level of access available for objects. When setting your Organization wide defaults, lock your data to the most restrictive level. Settings Available: Public Read/Write Public Read Only Private *This excludes Price books which have their own OWDs. For Public Read Only and Private additional access can be set up using role hierarchy or defining sharing rules. However, sharing rules can only open additional access, not restrict.   Profiles and Permission Sets Profiles and permission sets are collections of settings and permissions that determine what a user can do in the application. Profiles are typically defined by the user’s job function. Profiles can be assigned to many users, but each user can only have one profile. Permission sets grant additional permissions and access settings, multiple permission sets can be applied to a single user. Permission sets and profiles control a user’s object and field access permissions. Roles primarily control a user’s record level access through role hierarchy and sharing rules. If a permission is not enabled in the profile but is enabled through a permission set the user will be able to perform the action. Example: Use permission sets to grant access among logical groupings of users, regardless of their primary job function. For example, let’s say you have an Inventory custom object in your organization. Many users need “Read” access to this object and a smaller number of users need “Edit” access. To address this requirement, you can create a permission set that grants “Read” access and assign it to the appropriate users. You can then create...