Académique Documents
Professionnel Documents
Culture Documents
Implementation
Disclaimer
Customer Experience (CX)
Curriculum Development This document contains proprietary y information and is protected by
y copyright
y g and
other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered in
Technical Contributors any way. Except where your use constitutes "fair use" under copyright law, you may
and Reviewers not use, share, download, upload, copy, print, display, perform, reproduce, publish,
license, post, transmit, or distribute this document in whole or in part without the
Customer Experience (CX) express authorization of Oracle.
Product Development Team
The information contained in this document is subject to change without notice. If you
find any problems in the document, please report them in writing to: Oracle University,
Publisher 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
warranted
t d to
t be
b error-free.
f
Joseph Fernandez
Restricted Rights Notice
Trademark Notice
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Contents
1 Course Introduction
Lesson Agenda 1-2
Instructor and Class Participants 1-3
Training Site Information 1-4
Course Audience 1-5
Course Prerequisites 1-6
Course Goal 1-7
Course Objectives 1-8
Course Methodology 1-9
Course Materials 1-10
Course Agenda 1-11
iii
Setup and Maintenance 2-24
Schedule Processes 2-25
Resources 2-26
Oracle Cloud Site (cloud.oracle.com) 2-27
Oracle Cloud Customer Connect (https://ora-fusion-apps.custhelp.com) 2-28
My Oracle Support (support.oracle.com) 2-29
Oracle Help Center (docs.oracle.com) 2-30
Application Help 2-31
Embedded Help 2-32
Lesson Highlights 2-33
Practice 2-34
3 Getting Started
Objectives 3-2
Getting Oracle Sales Cloud 3-3
Verifying your Oracle Sales Cloud Instances 3-4
Verify the Administration Portal 3-5
Verify Access and Administrator Login to each Environment 3-6
Plan Your Implementation 3-7
What is Your Implementation Approach? 3-8
Comparing Approaches 3-9
Recommended Approach for Oracle Sales Cloud 3-10
Use a Solution-Driven Approach to Design 3-11
Use Configuration Rather than Customization Whenever Possible 3-12
Perform Incremental and Iterative Optimization 3-13
Good Project Management is Critical ...and Starts with a Solid Project Plan 3-14
Do Not Overlook these Planning Considerations 3-15
Key Implementation Concepts 3-16
Offerings 3-17
Enable the Offerings 3-18
Tasks 3-19
Run a Task from Within an Offering 3-20
Implementation Projects 3-21
Run a Task from within an Implementation Project 3-22
Run a Task from the Setup and Maintenance Home Page 3-23
Recommendation: Download the Quick Start Implementation Project 3-24
Install the Quick Start Implementation Project 3-25
Start the Quick Start Implementation Project 3-26
Implementation Overview 3-27
Review the Company Profile 3-29
Confirm the Enterprise 3-30
iv
Confirm the Legal Address 3-31
Confirm the Legal Entity 3-32
Confirm the Default Business Unit 3-33
Verify that the Initial Set of Tasks is Complete 3-34
Lesson Highlights 3-35
Practices 3-36
4 Security Overview
Objectives 4-2
Business Challenge and Solution 4-3
Authentication 4-4
Authorization 4-5
Visibility 4-6
Summary 4-7
Security Overview 4-8
Role-Based Access Control (RBAC) 4-9
Benefits of Role-Based Access Control 4-10
RBAC in Oracle Sales Cloud: Overview 4-11
Privileges 4-12
Policies 4-13
Application Roles 4-14
Top-Level Application Roles 4-15
User 4-16
Summary 4-17
Security Overview 4-18
Visibility 4-19
Benefits of Visibility Control 4-20
Visibility in Oracle Sales Cloud: Overview 4-21
Ownership 4-22
Territories 4-23
Team Membership 4-25
Hierarchies 4-26
Summary 4-27
Recommended Practices 4-28
Lesson Highlights 4-29
Practices 4-30
5 Setup Users
Objectives 5-2
Setup Users 5-3
Setup Users: Key Concepts 5-4
v
Role Provisioning Rules 5-5
Jobs 5-7
Autoprovisioning 5-8
Creating Setup Users: Flow 5-9
Implementation Overview 5-10
Create Setup Users 5-11
1. Create a Dummy Job 5-12
2. Create a Role Provisioning Rule 5-13
3. Create One or More Setup Users 5-15
4. Test the Results 5-18
Lesson Highlights 5-19
Practice 5-20
6 Profile Options
Objectives 6-2
Profile Options 6-3
Profile Options Example - Opportunity 6-4
Profile Option Values 6-5
Naming Conventions 6-6
Profile Option Tasks 6-7
Searching for Profile Values 6-8
Profile Option Levels 6-9
Edit a Profile Option 6-10
1. Invoke the Appropriate Task 6-11
2. Locate and Edit the Option 6-12
Editing Option Levels 6-13
Lesson Highlights 6-15
Practice 6-16
7 Lookups
Objectives 7-2
Lookups 7-3
Lookup Components 7-4
Lookup Values 7-5
Customization Level 7-6
Identifying Lookups 7-7
"Manage Standard Lookups" Task 7-8
Specific Lookup Tasks 7-9
User Interface 7-10
Implementer Responsibilities 7-12
Edit the Lookup 7-13
vi
Verify the Lookup 7-14
Create a New Lookup 7-15
Lesson Highlights 7-16
Practice 7-17
8 Accounting Calendar
Objectives 8-2
Oracle Sales Cloud Accounting Calendar 8-3
Implementation Overview 8-5
Implementer Responsibilities 8-6
1. Specify the Calendar Details 8-7
2. Specify the Period Frequency 8-8
3. Verify the Calendar 8-9
4. Add Calendar Periods 8-10
5. Enable the Calendar 8-11
Enable Time Periods for Business Intelligence 8-12
Lesson Highlights 8-13
9 Currencies
Objectives 9-2
Currencies 9-3
Implementation Overview 9-4
Oracle Sales Cloud Default Currency 9-5
Default Currency for Transactions 9-6
Exchange Rates 9-7
Currency Tasks 9-8
Multicurrency Opportunities 9-9
Lesson Highlights 9-10
Practices 9-11
10 Geographies
Objectives 10-2
A Geography in Oracle Sales Cloud 10-3
Implementation Overview 10-4
Geography Type 10-5
Geography Structure 10-6
Geography Hierarchy 10-7
Import Master Geography 10-8
Monitor the Import 10-9
Verify the Import 10-10
Manually Create Geographies 10-11
vii
1. Define the Structure 10-12
2. Define the Hierarchy 10-13
Geocoding 10-14
Addresses 10-15
Address Format 10-16
Address Cleansing 10-17
Enable Address Cleansing 10-18
Address Validation 10-19
Geography Type Mapping 10-20
Geography List of Values 10-21
Geography Validation 10-22
Recommended Practices 10-23
Geography Types 10-24
Geography Validation 10-25
Enabling LOVs 10-26
Resolving Mismatches 10-27
Lesson Highlights 10-28
Practices 10-29
11 Search
Objectives 11-2
Implementation Overview 11-3
Global Search 11-4
Recent Items 11-5
Filtering Results 11-6
Configure Global Search 11-7
1. Enable Global Search 11-8
2. Deactivate Unused Objects 11-9
3. Configure Recent Items 11-10
4. Configure Other Parameters 11-12
Work Area Search 11-13
Work Area Search Indexing Jobs 11-14
Recent Items 11-15
Configure Work Area Search 11-16
Saved Searches 11-17
Lesson Highlights 11-18
Practices 11-19
12 Classification Categories
Objectives 12-2
Business Challenge and Solution 12-3
viii
Classification Categories 12-4
Classification Groups 12-5
Why Use Classification Categories? 12-6
Features of Classification Categories 12-7
Name, Meaning, and Description 12-8
Parent Codes 12-9
Multiple Codes 12-10
Entity Assignment 12-11
Classification Codes 12-12
Use Classification Categories 12-13
Create a New Classification Category 12-14
1. Create the Category and Set its Options 12-15
2. Add Hierarchy Nodes 12-16
3. Add the Category to a Group 12-17
4. Assign and Test the Category 12-18
Use Case: Auxiliary Dimensions for Territories 12-19
Lesson Highlights 12-20
Practice 12-21
ix
14 Sales Users
Objectives 14-2
Review: Creating Setup Users 14-3
Sales Users 14-4
Implementation Overview 14-5
Sales Users: Key Terms and Concepts 14-6
Sales Resource 14-7
Resource Organizations 14-8
Resource Organization Hierarchy 14-9
Creating the Resource Organization Hierarchy 14-10
Resource Role 14-11
Summary of Provisioning Sales Users 14-12
Security: The Resource Role 14-13
Prepare to Create Sales Users 14-14
1. Plan the Hierarchy 14-15
2. If Necessary, Create Additional Resource Roles 14-16
3. Create a Top-Level Resource Organization 14-17
4. If Necessary, Create or Modify Provisioning Rules 14-18
5. (Optional) Configure Password Notification 14-19
Create a User 14-20
1. Create the User 14-21
2. Provision Roles 14-22
3. Verify the Results 14-23
4. Import the Remaining Users 14-24
Lesson Highlights 14-25
Practices 14-26
15 Security Console
Objectives 15-2
Business Challenge and Solution 15-3
Oracle Security Console 15-4
Manage Users 15-5
Manage Users: Example 15-6
Set Default Username and Password Policies 15-7
Configure Notifications 15-8
Configure Notifications: Example 15-9
Manage Security Roles 15-10
Examine an Existing Role: Roles and Privileges 15-11
Roles and Privileges: Table View 15-12
Roles and Privileges: Simulate Navigator 15-13
Create New Roles 15-15
x
Copy Existing Roles 15-16
Example: Create a "Sales Representative with Partner Access Role" 15-17
Compare Two Roles 15-20
Examine an Existing Role: Users Associated with the Role 15-21
Verify the Results 15-22
Security Considerations 15-23
Lesson Highlights 15-24
Practices 15-25
16 Sales Catalogs
Objectives 16-2
Implementation Overview 16-3
Sales Catalog in Oracle Sales Cloud 16-4
Product Groups 16-5
Using the Sales Catalog 16-7
Creating a Sales Catalog 16-8
Create a Sales Catalog 16-9
1. Create the Root Product Group 16-10
2. Create the Product Group Hierarchy 16-11
3. View the Product Group Hierarchy 16-12
4. Publish the Sales Catalog 16-13
5. Enable the Sales Catalog 16-14
6. Refresh the Product Catalog Table 16-15
Verify the Catalog Appears 16-16
Considerations 16-17
Lesson Highlights 16-18
Practice 16-19
xi
Download a Template 17-14
Build the Source File 17-15
Running a File-Based Import Job 17-16
1. Create the Import Job 17-17
2. Verify the Mapping 17-18
3. Submit the Import Job 17-19
4. Check the Status 17-20
4. Check the Status: View Details 17-21
5. Verify the Import 17-22
Reusable Mappings 17-23
Exporting Data 17-24
Export Records 17-25
Generate the Export File 17-26
Recommended Practices 17-27
Managing Record IDs 17-28
Preparing Source Data 17-29
Sequencing 17-30
File Management 17-31
Additional Import Methods 17-32
Lesson Highlights 17-33
Practice 17-34
18 Leads
Objectives 18-2
Business Challenge: Pursuing Leads 18-3
Implementation Overview 18-4
Lead Features 18-5
Lead Lifecycle in Oracle Sales Cloud 18-6
1. Add Leads to the System 18-7
2. Assign Leads 18-8
3. Evaluate and Qualify Leads 18-10
4. Convert Leads to Opportunities 18-11
Implementer Responsibilities 18-12
Set Lead Profile Options 18-13
Import Leads 18-14
Create Lead Rules 18-15
Lesson Highlights 18-16
Practice 18-17
19 Opportunities
Objectives 19-2
xii
Implementation Overview 19-3
Opportunities in Oracle Sales Cloud 19-4
Sales Methods 19-5
Specify the Sales Method 19-6
Sales Stages 19-7
Edit Sales Methods 19-8
Edit Sales Stages 19-9
Sales Stage Actions 19-10
Action Items 19-11
Manage Action Items 19-12
Recommended Documents 19-13
Manage Recommended Documents 19-14
Assessment Templates 19-15
Manage Assessment Templates 19-16
Other Options 19-17
Profile Close Options 19-18
Lesson Highlights 19-19
Practice 19-20
20 Assessments
Objectives 20-2
Implementation Overview 20-3
Assessments 20-4
Lead Assessment Example 20-5
Opportunity Assessment Example 20-6
Assessment Templates 20-7
Questions 20-8
Question Weight 20-9
Responses 20-10
Response Score and Rating 20-11
Assessment Score 20-12
Assessment Graph 20-13
Score Range Attributes 20-14
Implementer Responsibilities 20-15
Create Template 20-16
Test Assessment 20-17
Deploy Assessment 20-18
Lesson Highlights 20-19
Practice 20-20
xiii
21 Oracle Social Network
Objectives 21-2
Oracle Social Network (OSN) 21-3
Implementation Overview 21-4
Oracle Social Network Integration 21-5
Oracle Social Network Functionality 21-7
Configure Oracle Social Network for Oracle Sales Cloud 21-9
1. Enable Oracle Social Network for each Supported Object 21-10
2. Specify Wall Attributes for each Enabled Object 21-11
3. Specify Whether to Share Automatically 21-12
4. Synchronize with OSN 21-13
5. Verify the Results 21-14
Lesson Highlights 21-15
Practice 21-16
22 Territories
Objectives 22-2
Implementation Overview 22-3
Territories 22-4
Why Use Territories? 22-5
How are Territories Used? 22-6
Territories in Oracle Sales Cloud 22-7
Territory Types 22-8
Territory Hierarchy 22-9
Oracle Sales Cloud Dimensions 22-10
Dimensions 22-11
Defining Dimension Values 22-12
Geography Zones 22-13
Territory Coverage 22-15
Assigning Territories 22-16
Create a Territory Hierarchy 22-17
Creating a Territory Hierarchy: Example 22-18
1. Plan the Hierarchy 22-19
2. Enable and Configure the Appropriate Dimensions 22-20
3. Create a Territory Proposal 22-21
4. Create a Root Territory 22-23
5. Add Child Territories 22-24
6. Perform a Gap and Overlap Analysis 22-25
7. (Optional) Examine Territory Analytics 22-26
8. Activate the Territory Proposal 22-27
Configure Territory Options 22-28
xiv
End User Territory Management 22-30
Lesson Highlights 22-31
Practices 22-32
23 Territory Assignment
Objectives 23-2
Implementation Overview 23-3
Territory-Based Assignment 23-4
Key Concepts for Territory-Based Assignment 23-5
Assignment Objects 23-6
Assignment Object Attributes 23-7
Territory Assignment Mapping 23-8
Assignment Mapping Types 23-9
Mapping Sets 23-11
Multiple Mapping Sets 23-12
Default Territory Mappings 23-13
Duties Associated with Mapping Sets 23-14
Enable an Auxiliary Dimension 23-15
1. Enable the Dimension 23-16
2. Load and Activate the New Dimensions 23-17
3. Edit the Territories to Use the New Dimension 23-18
4. Test the Results 23-19
Disabling an Unused Dimension Mapping 23-20
Reporting and Metrics Options 23-21
Assignment Diagnostics 23-22
Tasks to Manage Assignment Objects 23-23
Resources and Considerations 23-24
Lesson Highlights 23-25
Practices 23-26
24 Rule-Based Assignment
Objectives 24-2
Implementation Overview 24-3
Technical Challenges and Solution 24-4
Rule-Based Assignment 24-5
Assignment Modes 24-6
Scoring Rules 24-7
Scoring Rules: Use Case 24-8
Classification Rules 24-9
Classification Rules: Use Cases 24-10
Matching Rules 24-11
xv
Matching Rules: Use Case 24-12
Rule Processing 24-13
Organization of Rules 24-14
Rule 24-15
Rule Set 24-16
Rule Category 24-17
Implement Rule-Based Assignment 24-19
1. Design the Rule 24-20
2. Edit Profile Options to Enable Rule-Based Assignment for the Object 24-21
3. (Optional) Create custom rule categories for the desired assignment modes 24-22
4. Create each Rule Set and Associate it with its Rule Category 24-23
5. Add Rules to each Rule Set 24-24
6. Schedule Rule-Based Assignment 24-26
7. Test the Rules 24-27
Lesson Highlights 24-28
Practices 24-29
25 Forecasting
Objectives 25-2
Implementation Overview 25-3
Forecasting 25-4
How Opportunities Are Included in a Forecast 25-5
Sales Representative Functionality 25-6
Sales Manager Functionality 25-7
Forecast Prerequisites 25-8
Key Concepts 25-9
Forecast Period 25-10
Submission Window 25-11
Opportunity Win Probability 25-12
Forecast Criteria Override 25-13
Enable Product Totals 25-14
Implementer Responsibilities 25-15
Set Forecasting Options 25-16
Schedule Forecast Processes 25-18
Considerations 25-20
Lesson Highlights 25-21
Practice 25-22
xvi
Extensibility 26-4
Extensibility Tools 26-5
Oracle Application Composer 26-6
Customize Standard Business Objects 26-7
Create New Custom Objects 26-8
Manage Custom Object Security 26-9
Manage Object Relationships 26-10
Create Business Object Workflows 26-11
Create Global Functions 26-12
Customization Issues 26-13
Sandboxes 26-14
Sandbox Activation 26-15
Changes Made in a Sandbox 26-16
Sandbox Publishing 26-17
Recommendations and Considerations 26-18
Resources 26-19
Lesson Highlights 26-20
27 Migration
Objectives 27-2
Implementation Overview 27-3
Business Challenge and Solution 27-4
Migration Tools 27-5
Before you Start 27-7
Sanity Checks 27-8
Functional Setup Manager 27-9
Use Functional Setup Manager 27-10
Customization Set Migration 27-11
Customization Migration General Steps 27-12
Migrate Customizations 27-13
1. Stop Mainline Modifications During Migration 27-14
2. Create a Customization Set 27-15
Wait for the Process to Complete and Review the Log File 27-16
3. Download the Customization Set 27-17
4. Upload the Customization Set 27-18
5. Apply the Customizations 27-19
6. Perform Post-Import Work 27-20
Restoring Customizations 27-21
Migrate Users and Accounts 27-22
Territories 27-23
Transactional Data 27-24
xvii
More Post-Import Tasks 27-25
Considerations and Recommended Practices 27-26
Lesson Highlights 27-28
A Access Levels
Objectives A-2
Review: Visibility A-3
Review: Who has Access to a Record A-4
Access Levels A-5
Full Access A-6
Viewing Records for Which you have Full Access A-7
Edit Access A-8
Viewing Records for Which you have Edit Access A-9
View Access A-10
Viewing Records for Which you have View Access A-11
Access Levels by Record Type A-12
Account, Contact, or Household A-13
Lead or Opportunity A-14
Lesson Highlights A-15
B Sandboxes
Objectives B-2
Customizations: Possible Issues and Solutions B-3
Sandboxes B-4
When Should You Use a Sandbox? B-5
Active Sandboxes B-6
Publishing a Sandbox B-7
Deleting a Sandbox B-8
Recommended Practices B-9
Using an Integration Sandbox B-10
Protecting Publication B-11
Sandbox Life Cycle B-12
xviii
Additional Considerations B-13
Conflict Resolution B-16
Using Sandboxes B-17
Lesson Highlights B-18
xix
16
Sales Catalogs
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Create a sales catalog
• Describe how a sales catalog is used in the application
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• I a collection
Is ll ti off products
d t and d product
d t groupings
i
– Products are that which your company sells to your customers
— May be physical products or intangibles such as licenses or service contracts
— May be added to opportunities and leads as revenue items
• A groupings
Are i off individual
i di id l products
d t
• Are useful when the individual product is not known yet
• For example, a sales person can add Laptops to an opportunity during early processing
and then change it to the 1000 Pro as the opportunity becomes more specific
Laptops P d t Group
Product G
Products
1000 Pro ThinkBook
Continued...
• The sales
Th l catalog
t l contains
t i a hihierarchy
h off product
d t groups
– Includes a root product group that is the top level of the hierarchy
– May contain subgroups, such as a product line
– May contain individual products
Root Product
ABC Electronics Group
Subgroups
Computer Systems Office Equipment
Products DG650 S
Server DG670 S
Server
Oracle Sales Cloud currently supports one sales catalog. It should be a rollup catalog meaning a
product group or product should appear only once. This ensures that if you create a forecast by
product, double counting does not occur.
Product groups can be empty (they do not need to contain products or other groups).
• Sales
S l representatives
t ti mustt add
dd a revenue item
it tto an opportunity
t it or lead
l d tto designate
d i t
revenue
– A revenue item must have an associated product or product group
• Sales representatives add revenue items by:
– Searching for a product or a product group directly
— Useful when you know what you want to add
– Browsing the sales catalog
— Useful when you want to view the entire catalog and make a selection
• The sales catalog is also used in reporting
• I performed
Is f d by:
b
– First building a hierarchy of product groups
— You do not create a catalog (there is no such object)
— Create product groups
— A root product group
— Any number of subgroups
— Product groups may be imported
– Then optionally creating products and adding them to the appropriate product group
— Products may be imported
For details on importing, see Understanding Import and Export in Oracle Sales Cloud Implementing
Sales.
1 Create
1. C t ththe Root
R t Product
P d t Group
G
2. Create the Product Group Hierarchy
3. View the Product Group Hierarchy
4. Publish the Sales Catalog
5. Enable the Sales Catalog
6. Refresh the Product Catalog Table
More
• Use th
U the "M
"Manage P Product
d tGGroups"" task
t k Internal name
to create the root product group Name shown in the
end user interface
– Name is internal and not displayed
– Display is shown in the catalog
– Deselect Allow Duplicate Children
for all product groups
— The same product group may not
appear in the hierarchy multiple Make active
times
Do not allow duplicates
– Select Root Catalog
Set Root Catalog
• Use th
U the S
Subgroups
b ttab
b tto add
dd additional
dditi l product
d t groups or products
d t tto bbuild
ild outt th
the
hierarchy
– A product group must be locked prior to adding product groups or products
• Use th
U the ttree view
i di
display
l option
ti tto show
h th
the groups iin a hi
hierarchy
h
– Caveat: Make sure you have highlighted the root product group prior to switching to
the tree view
Products and product groups may be imported. For more information, consult the Oracle Sales
Cloud training on Import/Export.
• Use P
U Publish
bli h to
t generate
t the
th catalog
t l b basedd on th
the product
d t group hi
hierarchy
h
– Make sure the root group is selected and locked
– Once you publish a product group:
— You cannot delete it
— You can make it inactive so it will not be displayed in the catalog
If you import any of your product groups you will not need to publish the catalog. The import process
automatically publishes all product groups.
• Use th
U the "M
"Manage PProduct
d tG Group UUsage"" ttaskk tto make
k the
th catalog
t l available
il bl tto O
Oracle
l
Sales Cloud users
– Assign your root product group to the Base usage
– Recall: Only a single catalog can be assigned
This task is also used to set additional options for the catalog:
• How the catalog is displayed
• Enforcing product territory restrictions
• And so forth
• Create
C t a new opportunity
t it andd verify
if th
thatt
the catalog appears when trying to add
a product
Catalog browsing from an opportunity is enabled by default. Modify a profile option to disable:
Profile Option Name = "Browse Sales Catalog in Opportunities Enabled"
Profile Option Code = MOO_ENABLE_BROWSE_CATALOG
Set to "N"
• F phase
For h one implementations,
i l t ti create
t a catalog
t l that
th t includes
i l d only
l product
d t groups
– Creating products is optional
• When adding products or product groups, the parent product group must be locked
• When publishing the product catalog, any locked product groups are published
– Unlock any product groups you don't want published
• A sales
l catalog
t l iis b
built
ilt using
i product
d t groups
– Product groups include subgroups and products
– Create one rollup catalog for use in Oracle Sales Cloud
• B ild a sales
Build l catalog
t l
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Describe the role of file-based import
• Import customer data
• Export user records to a file
• Customers:
C t
– Can use the Oracle Sales Cloud UI pages to enter, update, and delete small amounts
of data
– Need to use Oracle Sales Cloud bulk data management utilities:
— To import larger amounts of data from external or legacy systems into the sales base
tables
— To export sales data into external files
• IIncludes
l d utilities
tiliti to
t import
i t data
d t from
f and
d exportt data
d t to
t files
fil
– Supports multiple file formats:
— Standard text files with delimiters such as commas and tabs
— XML files
— Multiple CSV files contained in a ZIP file
• Are based on reusable mappings
• Can be run immediately or scheduled
Import Export
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• Key activities
K ti iti iinclude:
l d
– Understanding the data to be imported
– Preparing the source data
– Running an import job
More
• Identify
Id tif the
th constraints
t i t on data
d t when
h you entert records
d manually
ll
– Required fields
– Values for lookups to be populated
– Possible child records that can be entered
• Records imported must satisfy the same constraints
Required
field
• P id unique
Provide i record
d id
identifiers
tifi
• Select a mapping template
• Build the source file
More
• All records
d iin th
the O
Oracle
l SSales
l Cl
Clouddddatabase
t b h
have a system-generated
t t d unique
i
identifier
– Is created automatically when a record is created or imported
– Is not made visible to users within the Oracle Sales Cloud UI
• Records to be imported should have user-provided identifiers that are used:
– To determine if a record being entered is an existing or new record
– To identify the parent record to associate an imported child record with
Record Associations: Record identifiers are also used to support record association; for example, if
you want to import contacts associated with an account you must provide the account's record
identifier for each contact. More details are provided in a separate course on record import/export.
Typically, you want to use the user-provided identifiers whenever possible for such associations.
• Oracle
O l Sales
S l Cl
Cloud:
d
– Requires that many records imported using file-based import include:
— An identifier of the source system
— A unique identifier for the record in the source system
— This provides a user key for the source system
– Uses the source system references to determine whether an imported record is
already in the application
– Uses source system references for trading community objects
— Accounts, contacts, households, and so forth
Source system
reference
f in
i
source data file
You typically use the primary key of the record in the external system as the source system
reference identifier.
• Use th
U the "M
"Manage T
Trading
di C Community
it SSource S
Systems"
t " ttaskk tto create
t a record
d for
f a new
source system
You can set the Type to Spoke or Purchased. Select Purchased for an external source system, such
as Dun & Bradstreet, and Spoke for internal source systems, such as a legacy system.
Select the "Enable for Trading Community Members" check box if the source system is used to
obtain party data in the Oracle Fusion Trading Community Model, or Oracle Fusion Trading
Community Hub.
You must create the source system reference prior to importing data from that source system.
• F text-based
For t tb d iinputt fil
files, start
t t with
ith a mapping
i
– Use the "Manage File Import Mappings" task to select a mapping for the primary
object
— Oracle provides seeded mappings for many objects
— Previously-created customized mappings can also be selected
Search for
p
specific mapping
pp g
by name or …
… search for
specific
mappings for an
object
For accounts, search for Account Create and Update Seeded Mapping and download the template
from this mapping. In your application, the seeded mapping may be prefixed with the word OLD:
OLD-Account Create and Update Seeded Mapping.
For contacts, search for Contact Create and Update Seeded Mapping. In your application, the
seeded mapping may be prefixed with the word OLD: OLD-Contact Create and Update Seeded
Mapping
• V if th
Verify the mapping
i contains
t i ththe fields
fi ld you need
d ffor iimporting
ti
• Copy and modify the mapping if required
– Add or remove columns
• I a two
Is t row .csv file
fil with
ith
– Row of column headers
– Row of sample data
• Templates provided for many objects
• D l t th
Delete the row off sample
l ddata
t ffrom the
th template
t l t
• Add rows to the file for each record to be imported
– Provide a value for all required fields
– Make sure the values for lookup fields are valid
• When adding multiple child records, do not repeat the parent record fields
Two
Leave addresses
blank for the
account
1 Create
1. C t ththe iimportt job
j b
2. Verify the mapping
3. Submit the import job
4. Check the status
5. Verify the import
More
This procedure assumes that you, or someone on your team, has previously identified the source
data to be imported and the corresponding import objects and attributes that are to be populated.
This is also referred to as Classic Import.
• Use th
U the "M
"Manage Fil
File IImportt Activities"
A ti iti " ttaskk tto create
t a new activity
ti it
– Name the task
– Specify the import object
– Specify the type and location of the import file
– Specify the mapping used for the template file
• E
Examine
i ththe mappings
i th
thatt are automatically
t ti ll created
t d ffrom th
the iimportt mapping
i
If you do not provide a mapping, you can manually create the mapping by specifying for each
column the corresponding target object and attribute. You select a target object from the list of
objects associated with the import object.
• Schedule
S h d l th
the jjob
b
– Can select to run once immediately, at a regular interval, or at a fixed time in the
future
• Activate the job
• Monitor
M it ththe status
t t on the
th Manage
M Import
I t Activities
A ti iti page
– Use the refresh button to update the status
– Wait until the status reaches completed
Click to
refresh status
• Drill
D ill d
down on th
the status
t t tto view
i th
the activity
ti it ddetails
t il
– Monitor activity during the import
– Review the activity after import has completed
Current
status
Logged
messages
If status showed errors, you will see the errors in the logged messages.
• Ensure that
E th t the
th user who
h iis verifying
if i ththe import
i t has
h access to
t the
th d
data
t
– For example, an administrator
• Navigate to the appropriate page and search for the records that were imported
• Mappings
M i th
thatt are created
t d during
d i jjob
b submission
b i i are saved d
– Are named using the job name plus the submission time
– Can be referenced in subsequent jobs
• Specify the saved mapping on the Set Up page
– Can be downloaded as a template for users to add new data
• O l Sales
Oracle S l Cl
Cloud
d supports
t exporting
ti records
d tto a flflatt fil
file
• Can be used to:
– Verify data imports
– Determine record identifiers of existing records to which you wish to associate
imported child records
• Use th
U the "S
"Schedule
h d l E Exportt P
Processes"" ttask
k tto exportt records
d
– Name the task
– Specify one or more objects to be exported
– Specify the fields to be exported
Additional Task: There is also a task called "Manage File Data Export" which can be used to export
data. The key difference between the two processes is that the "Manage File Data Export" process
maintains the parent child hierarchy while the "Schedule Export Processes" does not. More details
on the "Manage File Data Export" process are provided in a separate course on import/export.
• A ti t the
Activate th task
t k
• Examine the generated file
Displays a
selected set
of fields
System-generated internal
record Id created whenever
a new record is created
• M
Managing
i R Record
d IDs
ID
• Preparing Source Data
• Sequencing
• File Management
More
For more information on recommended practices, see Oracle Sales Cloud File Import Mapping and
Supporting Instructions (Doc ID #1596128.1) on My Oracle Support.
• Create
C t iintelligent
t lli t kkeys.
– Include object reference, for example ORG, LOC, SITE, REVLINE
– Dates
– Sequential Numbers
• Keep track of all keys you create
– Makes sure you don't inadvertently reuse one
– Allows you to add child records in the future
• Cl
Clean the
th ddata
t
• Eliminate the unnecessary
– Decide how much history you really need
• Validate the data before running an import job
– Run a small-volume import of perhaps 10 records to ensure:
— The import
p is configured
g correctly
y
— Data is acceptable for import and does not generate errors
— Make sure lookup values are valid
• Start with a template where possible
• Breakk an import
B i t into
i t smaller
ll pieces
i
– Do not attempt to import the parent and all the child records in a single file import task
• Example:
– Import the Organizations/Sales Accounts with multiple Addresses and Primary Phone
and Email
– Enrich Organizations with multiple Phone Numbers
– Import Contacts for the Organizations, with their multiple Addresses
– Enrich Contacts with multiple Phone Numbers
• Recommended
R d d practice
ti iis tto use th
the ZIP fformatt containing
t i i multiple
lti l CSV fil
files whenever
h
possible
• Keep your files organized
– Self document as much as possible
– Use the approach seen in the templates of having TargetObject_TargetAttribute as
the Header Row in the input files – makes mapping much easier
– Keep every file used during file import – in sequence
— Allows you to examine previous imports and determine what happened after the fact
— Files used during the imports are not currently accessible from Oracle Sales Cloud
— Try to avoid updating an earlier file and re-running it with new data and/or mapping
Users who will be involved in import activities should take the Oracle University course.
• File-based
Fil b d iimportt iis an O
Oracle
l SSales
l ClCloud
d ffeature
t th
thatt allows
ll users tto iimportt records
d
from external files
– Supports a variety of files (text and xml)
– Can be run immediately, or scheduled once, or recurring
– References import objects that define the structure of the data to be mapped to the
interface tables
• Prepare the
P h iinput d
data b
by:
– Identifying required fields and valid lookup values
– Creating record Ids
• To run file-based import:
– Specify the import object and the location of the source file
– Create the mapping
– Activate the job
• I
Import
t and
d exportt records
d
Leads
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Define leads and describe how they are used in the Oracle Sales Cloud application
• Configure lead options
• Companies
C i llearn off h
hundreds,
d d if nott th
thousands,
d off potential
t ti l sales
l adday, th
through:
h
– Sales campaigns
– Corporate events, such as conventions
– Purchases of data from third-party vendors
– Eloqua or other marketing campaigns
– Sales Predictor
– And so forth
• In Oracle Sales Cloud, such potential sales are called leads
– A person or party demonstrating potential interest in purchasing a product or service
• Leads must be processed in an efficient manner
– How do you determine which leads are worth pursuing?
– Who is responsible for making that determination?
– Who is responsible for following up on good leads?
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• Leads
L d may b
be associated
i t d with:
ith
– Contacts: May be existing or new
– Accounts: May be existing or new
– Products: Products associated with the potential sale
• Leads have additional functionality:
– Owners assigned to a lead may reject the lead, forcing reassignment
– Once a lead is determined "strong enough", it may be converted to an opportunity
— Contact is verified
— Purchase interest is qualified
— Lead is considered worth pursuing as an opportunity
— Exact criteria vary from company to company
1 Add lleads
1. d tto th
the system
t
2. Assign leads
3. Evaluate and qualify leads
4. Convert leads to opportunities
4. Convert leads to
opportunities
Assign Leads: The way leads are assigned varies based on your business requirements.
Sometimes leads are first assigned to Inside Sales Representatives for further evaluation.
Sometimes they are assigned directly to Sales Representatives, who both qualify and convert the
leads.
Evaluate and Qualify Leads: This can include verifying the contact, checking for duplicates,
automatic ranking and/or scoring of the leads, qualifying the leads (either manually or automatically),
using a qualification template for assessment of the lead, and so forth. The exact process depends
on your business requirements
requirements.
Convert Leads to Opportunities: This can include assessing leads using qualification templates,
verifying product interest, evaluating deal size, and so forth, and then converting the lead. The exact
process depends on your business requirements. Leads that are not converted are retired.
• Oracle
O l Sales
S l Cl
Cloud
d provides
id many ways tto add dd lleads
d tto th
the system:
t
– Sales Campaigns
– Sales Predictor
– Using batch import and import templates
– Using web services
– Manually
• In all cases, specifying contact, account, or product information are optional at this stage
– If contacts and/or accounts are specified, be sure to use the Check for Duplicates
action menu item to check for preexisting contacts or accounts
• Leads
L d may bbe assigned
i d using:
i
– Territory-based assignment
– Rule-based assignment
• For territory-based assignment, all leads (both qualified and unqualified) are assigned
matching sales territories
• For rule-based assignment,
g yyou mayy create different rules for q
qualified and unqualified
q
leads
– Useful if your business requirements assign unqualified leads to one set of users, and
qualified leads to another
Continued...
• Sales
S l representatives
t ti may acceptt or reject
j t leads
l d assigned
i d tto th
them
– Rejecting a lead returns it to the assignment pool for subsequent assignment
• Once a sales representative has accepted the lead, he or she works with the lead and
may:
– Retire the lead
– Convert the lead to an opportunity
• Oracle
O l SSales
l ClCloud
d provides
id multiple
lti l mechanisms
h i ffor evaluating
l ti lleads:d
– Scoring: A scoring rule can generate an overall score for the lead
— This score can then be used to rank, qualify, and/or assign the lead
– Ranking: A ranking rule can be used to rank the lead
– Qualification: A user can fill out an qualification template to evaluate a lead
— Can be used to assess the quality of leads
— H l iin iimplementing
Helps l ti a standardized
t d di d evaluation
l ti off lleads,
d rather
th ththan using
i subjective
bj ti
assessments
• Once a lead has been evaluated, it may be marked as:
– Qualified: The lead is worth pursuing
– Retired: The lead is not worth pursuing, and has been dropped from consideration
• Once a lead
O l d iis d
determined
t i d worth
th pursuing,
i th
the sales
l representative
t ti converts
t it tto an
opportunity
– Leads not worth pursuing are retired
• S t lead
Set l d profile
fil options
ti
• Import Leads
• Create lead rules
More
• U th
Use the "M
"Manage S
Sales
l L Lead
dPProfile
fil Options"
O ti " task
t k to
t sett lead
l d profile
fil options
ti
• Examples of profile options include:
There are many additional profile options associated with assignment rules. These will be discussed
in more detail in the lesson on rule-based assignment.
• Follow
F ll the
th standard
t d d batch
b t h iimportt process tto iimportt lleads:
d
– Use the "Manage File Import Mappings" task to download the lead import template
– Populate the spreadsheet with lead information
– Run an import job to import the leads
• Details on file imports are in another lesson
• Use the
U th "Manage
"M Sales
S l L LeaddAAssignment
i tR
Rules"
l " ttaskk tto create
t th
the necessary rules
l ffor
your particular implementation
– Scoring rules, if they are being used
– Ranking rules, if they are being used
– Assignment rules for unqualified leads, if they are being used
– Assignment rules for qualified leads
• Details on creating these rules are in another lesson
• Leads
L d representt potential
t ti l sales,
l and
d are added
dd d tto th
the system
t using:
i
– Imports
– Automated processes
– Manual data entry
• Implementers support the lead lifecycle by:
– Using profile options to configure lead behavior
– Performing file-based imports of leads
– Setting up rules to evaluate and assign leads
• C fi
Configure l d assignment
lead i t behavior
b h i
Opportunities
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Describe how opportunities are used in the Oracle Sales Cloud application
• Configure sales stages
• Set opportunity close options
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• A potential
Are t ti l sales
l
– Are typically associated with an account, contact, or household
– Have an assigned team
– May include a product or product group
• Are managed using sales methods
• G id sales
Guide l people
l th
through
h a structured
t t d sales
l process
• Contain sales stages that contain recommended practices the sales people should
follow at each stage of the opportunity
• Oracle Sales Cloud provides two predefined methods:
– Standard Sales Process: Useful for longer sales cycles with multiple decision makers
— The default method
– Accelerated Sales Process: Useful for shorter sales cycles and one decision maker
• Use a profile
U fil option
ti tto sett the
th sales
l method
th d to
t be
b used d ffor new opportunities
t iti
– Profile Display Name = Sales Method Default
– Profile Option Code = MOO_DEFAULT_SALES_METHOD
– Can be set for both the site and user level
– A user-specified level overrides a site level if both are present
All new opportunities will the use sales method specified by this profile option. By default sales
people cannot select or change this value.
• A the
Are th generall steps
t off a sales
l method
th d
– Delineate the progress of an opportunity
• Provide guidance to the sales person for handling the opportunity
• Standard Sales Process stages:
– Qualification and Discovery: Who might need our product?
– Building Vision: How will we sell to this customer?
– Presentation: How do we present our product to the customer?
– Agreement: Agreement that the customer needs the product
– Negotiation: Agreeing to price, terms, and so forth
– Closed: The opportunity has been won or lost, and is complete
• Use th
U the "M
"Manage Sales
S l M Methods
th d anddS
Sales
l Stages"
St " task
t k to
t edit
dit existing
i ti or create
t new
sales methods
– Select the sales method you want to edit
• It is recommended to not change the as-delivered sales method names
– Used in other areas of the application
– You may disable an as-delivered sales method
Standard Sales
Process method
• Select
S l t the
th sales
l stage
t you wantt to
t
edit within the method
• You may create a new sales stage
Order: Sales stages are listed according to the values in the Order column, with the lowest-order
sales stage of a sales method being the default sales stage for new opportunities. Be sure you order
your sales stages correctly, and do not duplicate order numbers.
Disabling as-delivered sales stages: If you decide not to use an as-delivered sales stage, be sure
to disable it rather than deleting it.
• Each
E h sales
l stage
t h
has configurable
fi bl actions
ti tto h
help
l guide
id salespeople:
l l
– Action Items
– Recommended Documents
– Assessment Templates
– Other Options
More
• A process steps
Are t the
th salesperson
l should
h ld follow
f ll while
hil an opportunity
t it iis in
i a sales
l stage
t
• Are displayed in the Sales Coach region of the opportunity
– More detail is provided when an action item is selected in the user interface
Action
Items
• Use th
U the P
Process St
Steps section
ti to t create,
t edit,
dit delete,
d l t and d reorder
d ththe steps
t th
thatt appear
in the Action Items section
– Determine the order and enter a step name
– Use the rich text editor to create the text displayed when the step is selected
Order displayed in
Sales Coach Name displayed in
Sales Coach
• Are coaching
A hi strategies
t t i and dbbest-practice
t ti information
i f ti relevant
l t tto the
th sales
l stage
t in
i the
th
form of documentation
– Displayed in the Sales Coach region of the opportunity
• May include competitive documentation
• May be documents, text, or URLs
Recommended
Documents
Th sales
The l person iis prompted
t d
to open or save the document
• Use th
U the R
Recommended
d dDDocuments
t section
ti tto create,
t edit,
dit delete,
d l t and
d reorder
d the
th
documents
Name Displayed in
Sales Coach
• Are interactive
A i t ti questionnaires
ti i di
displayed
l d iin th
the user iinterface
t f tto h
help
l salespeople
l l make
k
decisions
– Assessments are covered in a separate lesson
The assessment score helps the sales person determine if the opportunity is a viable fit for the stage.
• Use th
U the A
Assessmentt Templates
T l t section
ti to
t add
dd or remove assessments t
– Assessments are created independently and are covered in a separate lesson
• IImplementers
l t and
d administrators
d i i t t can sett various
i profile
fil options
ti when
h an opportunity
t it iis
closed
– Making fields required
– Determining a close date
– And so forth
• Use the "Manage Opportunity Profile Options" task to manage these options
Close Opportunity Win/Loss Reason Required MOO_CLOSE_WINLOSS_REQD Yes Determines if the user is required to enter a win or loss reason
Close Opportunity Competitor Required MOO_CLOSE_COMP_REQD Yes Determines if the user is required to enter a competitor
Determines the number of days after an opportunity is created for the initial
Opportunity Close Date Default MOO_DEFAULT_CLOSE_WINDOW 20
close date.
Tells the application to retain the old close date even after the status of the
Opportunity Close Date Retain on Closure MOO_RETAIN_CLOSE_DATE No
opportunity is set to a closed status
• O
Opportunities
t iti are potential
t ti l sales
l
• Sales methods guide the salesperson in managing the opportunity during the sales
process
• Sales methods contain sales stages with customizable actions and options
• S t opportunity
Set t it options
ti
Assessments
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Define assessments
• Describe how assessments are used in the application
• Configure assessments
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• Consist
C i t off questions
ti and
d responses th
thatt provide
id a score and
d rating
ti ffor a llead,
d
opportunity, account, contact, or household
– During the assessment process, the salesperson is presented with questions
– Responding to the questions provides the salesperson with immediate feedback such
as recommendations or follow-up business processes based on the assessment
score
• Examples:
– Evaluate the strength of a lead
– Evaluate the discount eligibility of an opportunity
• The questions
Th ti and
d responses calculate
l l t an assessmentt score and
d rating
ti that
th t helps
h l
identify the strength of the lead
• The score and rating are dynamically updated as the salesperson interacts with
questions
Assessment score
and rating
Responses from
Questions about the salesperson
the lead
• The questions
Th ti and
d responses calculate
l l t an assessmentt score and
d rating
ti that
th t helps
h l
identify if the opportunity is eligible for a discount
Assessment score
and rating
• Specify
S if a sett off questions
ti and
d responses
– System administrators create questions and responses
• Automatically calculate an assessment score and rating
• Template components:
– Questions
– Question Weight
– Responses
– Response Score and Rating
– Assessment Score
– Assessment Graph
– Score Range Attributes
More
• A the
Are th main
i components
t off an assessmentt
• Are grouped into logical collections called Question Groups
– Helps the user understand the type of questions to expect in each group
Question
Question being edited
group
Questions
in this
group
• R
Represents
t the
th relative
l ti iimportance
t off th
the question
ti within
ithi th
the assessmentt
• Is set by system administrators
• Is listed as a percentage
– The sum of all of the question weights in the assessment template must equal 100%
If the weights don't equal 100 you will be allowed to save the assessment template but not use it.
• A the
Are th available
il bl answers tto questions
ti
• May be a fixed list or free form
– A fixed list must include at least two choices
Question
Response choices
• A assigned
Are i d tto each
h possible
ibl response
– Score is used to automatically calculate a normalized response score
– Rating is used to calculate default score ranges for final ratings
Scores
The assessment template assigns a normalized score of 100 to the highest response score.
The assessment assigns all other responses a normalized score relative to the highest score.
You configure the available assessment ratings when you initially design the assessment.
• I the
Is th weighted
i ht d sum off the
th normalized
li d scores ffor each
h question
ti
– Question weight x normalized response score = weighted score for the question
Assessment Score
R
Responses with
ith normalized
li d
score displayed in parentheses
Questions with
weight displayed
in parentheses
Weighted scores
are summed
• P id a visual
Provides i l representation
t ti off th
the assessmentt score
• Is configured by administrators when the assessment template is created
– Is either be a line graph or gauge graph
– Has customizable colors
Line graph with
the score in the
graph and rating to
the right
• Define
D fi ththe rating
ti and d ffeedback
db k di
displayed
l d to
t the
th salesperson
l when
h ththe assessmentt score
falls within a score range
• Define the color displayed in the graph for the score range
• For example, if the assessment score is 27, the rating "Average" and feedback "This
lead has a moderate chance of going through" are displayed
The score ranges are initially calculated based on the scores and ratings you assign to responses.
You may edit these default ranges.
• C t T
Create Template
l t
• Test Assessment
• Deploy Assessment
More
• Use the
U th "Manage
"M Sales
S l L Lead
dAAssessmentt T
Template"
l t " ttask
k tto create
t a new assessmentt
template
Opportunity assessments are managed using the Manage Opportunity Assessment Templates task.
Account assessments are managed using the Manage Customer Center Assessment Template task.
• U th
Use the A
Actions
ti menu tto test
t t the
th assessmentt prior
i tot deploying
d l i it
• Use th
U the A
Actions
ti menu tto Deploy
D l th the assessmentt
– The assessment is available for use in the application
— Status is set from In Progress to Active
– Most editing of the assessment is disabled
— You may still edit the Feedback within the Score Range Attributes section
Only the selected template is deployed. To de-activate a template you must delete it. The status is
set to Retired.
• A assessmentt provides
An id sales
l people
l with
ith feedback
f db k on various
i objects
bj t
• Salespeople answer questions and their responses determine the assessment score
• Assessment templates contain questions, responses, and other assessment
components
• C t an assessmentt
Create
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Perform initial Oracle Social Network configuration
Oracle Social Network is available separately from Oracle Sales Cloud. This lesson focuses on
Oracle Social Network as integrated with Oracle Sales Cloud.
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• Supports
S t sharing
h i off sales
l objects
bj t ((accounts,
t contacts,
t t opportunities,
t iti leads,
l d andd so fforth)
th)
for sales team collaboration
– Supports both web client and mobile applications
• Is embedded directly within Oracle Sales Cloud
– Users navigate to Oracle Social Network pages from within the Oracle Sales Cloud
application
• Is context-specific
– Conversations initiated within Oracle Sales Cloud are shown in the context of the
account, contact, or other sales object
Continued...
• I available
Is il bl as a side
id ttab
b on supported
t d objects
bj t
• Every shared
E h d object
bj t h
has an associated
i t d ""conversation"
ti " th
thatt iincludes:
l d
– Members
— Sales team members
— Non-team members added to the conversation by existing members
– A "wall": A discussion area
– Related documents and conversations
– Links
Li k tto conversations
ti th
thatt refer
f tot the
th wallll
A shared Opportunity
Related
conversations
Documents related
to the opportunity
Team members and
other added users
Continued...
Wall = Discussion about the opportunity
• F enabled
For bl d objects,
bj t users may enable
bl OSN ((share)
h ) on a record-by-record
db dbbasis
i
• For enabled records, whenever specified fields are updated the wall is updated with
these updates
– Administrators specify these fields
1 Enable
1. E bl OOracle
l SSocial
i lNNetwork
t k ffor each
h supported
t d object
bj t
2. Specify wall attributes for each enabled object
3. Specify whether to share automatically
4. Synchronize with OSN
5. Verify the results
• Use th
U the "M
"Manage OOraclel S
Social
i lN
Network
t k Obj
Objects"
t " ttask
k tto enable
bl OOracle
l SSocial
i lNNetwork
t k
on an object-by-object basis
• Every enabled
E bl d object
bj t hhas a d
default
f lt sett off attributes
tt ib t already
l d configured
fi d
– These are shown on the wall whenever they are updated
• Use the bottom applet of the "Manage Oracle Social Network Objects" task to
add/remove attributes from this list
• To change
T h behavior
b h i ffrom th the d
default
f lt (M
(Manual),
l) click
li k E
Enable
bl Obj
Objectt and
d change
h th
the
sharing setting
– Caveat: Sharing all records automatically may impact the user experience, as
performance will be slower when creating records
• F each
For h object
bj t type:
t
– Create and share a new record
– Verify the wall is updated with the appropriate fields
• Oracle
O l SSocial
i lN
Network
t k allows
ll users tto di
discuss sales
l objects
bj t within
ithi th
the O
Oracle
l SSales
l
Cloud application
• Enable Oracle Social Network by:
– Enabling it for each desired object
– Specifying the attributes to update
– Specifying manual or automatic sharing
– Synchronizing
– Verifying the results
• Ad i i t O
Administer Oracle
l Social
S i l Network
N t k settings
tti in
i Oracle
O l S Sales
l ClCloud
d
Territories
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Define territories in Oracle Sales Cloud
• Manage territories
• Set territory management options
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• A used
Are db
by sales
l and d marketing
k ti organizations
i ti tto specify
if visibility
i ibilit access tto objects:
bj t
– Customers (Accounts, Contacts, and Households)
– Deals
– Leads
– Opportunities (Revenue Items)
– Partners
• Are required for forecasting
• Are arranged in a hierarchy
– For example, Global Sales may contain North America Sales East and North America
Sales West, which in turn contain subsidiary territories, and so forth
• Territories
T it i provideid a robust
b t mechanism
h i ffor automatically
t ti ll assigning
i i sales l tteam membersb
to customers, leads, and opportunities
– Territories are not based solely on geography, but support a variety of dimensions
— For example, company size, industry, or product
– Oracle Sales Cloud also supports rule-based assignment for more complex
assignment requirements
— Subject of a subsequent lesson
• Manually assigning each new lead, opportunity, or customer a sales representative or
other resource is not scalable
Territories and Security Roles: Territories are the recommended mechanism for limiting visibility to
leads and opportunities. Always consider how you might implement a requirement using territories
before considering creating customized security roles. Territories are both more maintainable and
more stable against upgrades.
Default Visibility: Without territory or rule-based assignment, only the owner (creator) of a lead or
opportunity has access to it, and he or she can add team members and grant them access. All sales
users have read-only access to accounts and contacts, but again, only the owner has write access,
and can add team members and grant them read/write accessaccess. Territories grant visibility (either read
read-
only, read/write, or full access) to records based on assignment and territory membership.
• Territories
T it i control
t l visibility
i ibilit access tto customers,
t lleads,
d and
d opportunities
t iti
– Territories are assigned to these objects
– Members of assigned territories have elevated access/visibility
— The type of access depends on the object type
— For example, opportunities are restricted such that only team and territory members can
see them
– Members of parent/grandparent territories (management) also have access/visibility
Non-members cannot
• A owned
Are d
– One resource (sales user) is the owner of a territory
– Other resources may be assigned to the territory
• Have boundaries that are defined by a combination of dimensions such as:
– Business unit within the sales organization
– Location of the account (geography)
– Type of account
– Size of account
– Products associated with a lead or opportunity
• Are classified into several types
– Some territory types should not overlap with each other
Some companies may assign sales personnel to accounts based on geography (for example, west
coast sales region and east coast sales region). Other companies may assign sales personnel
based on product line (for example, hardware and software). Still other companies may want to use
a combination of these, along with other dimensions.
Overlay Assign specialists who support sales with their technical expertise Yes
Partner Assign partners who are authorized to sell in the territory Maybe*
Channel Sales Route leads and opportunities to an internal employee, who then No
Manager manually assigns these records to specific partners
Partner Territories: If partner territories overlap, then more than one partner may be assigned to an
opportunity, leading to competition between the partners for the business. This is typically
undesirable, but depends on your business model. Oracle Sales Cloud does not prevent you from
creating overlapping partner territories.
• I the
In th sales
l cloud,
l d tterritories
it i are also l organized
i d hihierarchically:
hi ll
– At the root, a territory representing the entire market space for the enterprise
– A set of child territories representing specific areas of the market space
• Objects are assigned the most-specific possible territory
– For example, a New York software company would be assigned US East Software
Global
(Any, Any, Any)
US West US East
(Western US, any, any) (Eastern US, any, any)
Territory Hierarchy and Overlap: Territories at the same level in the hierarchy should not overlap
(with the exception of Overlay territories). Parent-child territories will overlap.
The value "any" indicates that the territory will accept any value for that particular dimension, so the
territory does not use that dimension to filter records. In particular, the "root" or "base" territory
should have values of "any" for all of its dimensions. That way all records (for example, accounts)
that are not assigned to territories lower in the hierarchy will be assigned to that root territory.
A particular territory's coverage is determined by the intersection of all of its dimensions.
• Oracle
O l Sales
S l Cl
Cloud
d provides
id 8 pre-defined
d fi d di
dimensions
i ffor d
determining
t i i tterritories:
it i
– Account Type
– Business Unit
– Customer Size
– Geography
– Industry
– Organization Type
– Product
– Sales Channel
• There are also 3 configurable auxiliary dimensions
A business unit represents the logical level within your enterprise where processes, policies, and
reference data vary. If your data model uses separate business units, then typically business units
map to the first level of your territory structure.
Geography, industry, customer size, organization type, account type, and account are all attributes of
sales accounts that can be used to assign territories.
Product and sales channel are attributes of opportunities that can be used to assign leads and
opportunity revenue lines.
• Separate
S t territories
t it i intoi t discrete
di t areas:
– For example, "North America" and "Europe" or "Sales Business Unit" and "Service
Business Unit"
• Assist in creating territory hierarchies
– For example, the "California" territory might have the same dimensions as the North
America territory, but with Country = United States and State = California
• Are not defined in terms of a large set of procedural rules
• Mostt dimension
M di i values
l come from
f lookups
l k or classification
l ifi ti categories:
t i
– Account Type
– Customer Size
– Industry
– Organization Type
– Sales Channel
– Auxiliary Dimensions
• Some are defined using criteria you defined previously in your implementation:
– Business Unit
– Product
• Geographies may require additional configuration
– Territories usually use groups of geographies called "Geography
Geography Zones"
Zones
• Mostt companies
M i d do nott conduct
d t th
their
i b
business
i along
l strict
t i t geographical
hi l b
boundaries
d i
– A sales representative is not assigned a single state, nor a single county, and so forth
• Geographies must be grouped into "bundles" of geography types that are managed by a
sales representative
– For example, a "U.S. West Pacific" sales representative may manage Alaska,
California, Hawaii, Oregon, and Washington
• Use the "Manage Territory Geographies" task to configure geography "zones"
– Zones are groups of geography types bundled together for use with territories
• O
Once geography
h zones have
h b
been configured,
fi d use th
them as tterritory
it di
dimensions
i
• Customers
C t ((accounts,
t contacts,
t t households,
h h ld and
d partners),
t ) leads,
l d and d opportunities
t iti are
associated with territories based on:
– Dimensional coverage: The customer is associated with the most-specific possible
territory
– Customer inclusion: Customers may be added directly to territories
– Customer exclusion: Customers may be specifically excluded from territories
• Territories
T it i are assigned
i d either:
ith
– Manually by the user invoking an action menu
– Automatically upon saving a new or edited record
• Territory assignment behavior depends on the profile options for the object
– For example, opportunities include a profile option that determines whether or not to
run assignment every time an opportunity is saved
1 Plan
1. Pl th
the hi
hierarchy
h
2. Enable and configure the appropriate dimensions
3. Create a territory proposal
4. Create the root territory representing the enterprise
5. Add child territories, including children, grandchildren, and so forth
– Each child territor
territory inherits b
by defa
default
lt the values
al es for the parent dimensions
– Specific values are then assigned to one or more dimensions
6. Perform a gap and overlap analysis
7. (Optional) Examine Territory Analytics
8. Activate the territory proposal
More
Root USTech
territory (geography: any, industry: any, size: any)
Values assigned to the
geography dimension
• Before
B f doing
d i anything
thi iin th
the application,
li ti carefully
f ll plan
l outt your tterritory
it hi
hierarchy:
h
– Think about the dimensions:
— Which dimensions will you use?
— Which dimensions are you sure you will never use?
— Will you need any additional (auxiliary) dimensions for your implementation?
— What geography zones will you need?
– Think about the assignments:
— Will you have one sales representative per territory, or multiple?
— If you have multiple sales representatives per territory, who will own the territory?
– Think about overlays:
— Will you have overlay territories for subject matter experts (SMEs) to assist sales
representatives?
— Will you be implementing partner territories?
• Perform
P f any prerequisite
i it workk ffor your dimensions
di i
– For example, create geographies and geography zones if you are going to use the
Geography dimension
• Use the "Enable Dimensions and Metrics" task to enable the dimensions you will use
– To improve performance, do not enable dimensions you are sure you will never use
• If necessary, enable one or more of the 3 auxiliary dimensions
– Discussed in a subsequent lesson
Navigation: The Enable Dimensions and Metrics task is either available from your implementation
project, or by navigating to Territories, clicking More Details, and clicking the Enable Dimensions and
Metrics link in the left pane.
Configuring Dimensions: Each as-delivered dimension has a "reasonable" default value; for
example, the Industry field uses a standard industry classification category. You may specify
alternative lookups or classification categories when you add the dimensions. Consider using the
defaults unless you have a strong business reason for changing them.
• Territory
T it proposals
l are containers
t i within
ithi which
hi h tterritory
it changes
h can bbe modeled
d l d and
d
evaluated without affecting the existing territory hierarchy in production
– Create a territory proposal when:
— First creating the territory hierarchy
— Updating the territory hierarchy or modifying territory dimensions
• Allow users to:
– Model
M d l changes
h tto tterritories
it i
– Assess the impact of changes
— How will revenue per territory change? How will number of opportunities per territory
change? And so forth
• Shield the production territories and assignments from the territory changes being
modeled
• Can b
C be activated
ti t d once th
they are validated
lid t d Continued...
– Replaces the existing production territories with the modified territory hierarchy
Copyright © 2017, Oracle and/or its affiliates. All rights reserved.
• U th
Use the tterritory
it managementt page to
t start
t t the
th "Manage
"M Territory
T it Proposals"
P l " task
t k
• Create a proposal
Navigation: The "Manage Territory Proposals" page is not available from the Setup and
Maintenance task list. Instead, navigate to Territories and click the More Details icon. On the left, you
will be able to start both the Manage Territory Proposals and Enable Dimensions and Metrics tasks.
• Create
C t a prime
i tterritory,
it allll off whose
h di
dimensions
i =A
Any
– This ensures all records are included in at least this top-level territory
• Specify an owner
– Every territory, even the root territory, must have an owner
Assigning an Owner: Typically, the "owner" is the sales representative (or other employee) you
want to have owner-level access to all customers, opportunities, leads, and partners associated with
that territory. For the root territory, objects assigned this territory have not been assigned any other
territories. This usually indicates an issue with the way territories are set up, so the root territory
typically has an application administrator as its owner.
• Create
C t additional
dditi l tterritories,
it i keeping
k i in i mind:
i d
– Prime territories at a particular level should not overlap
— Managed by setting dimensions appropriately
– Overlay and partner territories may overlap
— However, overlapping partner territories would make partners compete for business
When creating a territory you may specify which customers to include or exclude. If you find yourself
including or excluding a large number of customers, you should re-examine your territory plans.
Typically, including or excluding customers is done as an exception basis for particular customers,
not as a general approach to territory management. Also, including or excluding large numbers of
customers could impact performance.
• On the
O th territory
t it managementt page, select
l t a tterritory
it and
d select
l tA Actions
ti >V
Validate
lid t to
t
perform gap or overlap analysis
– Gaps show possible combinations of dimensions that are not covered by any territory
at that level
– Overlaps show combinations of dimensions that have multiple prime territories at that
level
– Both situations are undesirable
• Use th
U the AAnalytics
l ti ttab
b tto view
i iinformation
f ti about
b t number
b off customers,
t revenue, andd
market potential of the proposed territories
– Extremely useful in creating "balanced" territories such that each sales representative
is responsible for approximately the same amount of revenue
Reference: For more information on running the assignment processed, consult "Setting Up Sales
Territories and Assignment" in Oracle Sales Cloud Getting Started with Your Implementation.
• Use th
U the "D
"Define
fi T Territory
it M
Managementt Profile
P fil O Options"
ti " ttaskk to
t sett options
ti such
h as the
th
default territory proposal owner
– Used to assign generated proposals such as those that are generated when
synchronization errors occur
– Typically an administrator
• Use the "Define Territory Management Lookups" task to set options such as:
– Territory types
– Territory lines of business
– And so forth
Continued...
• Use th
U the "E
"Enable
bl Di
Dimensions
i and
dM Metrics"
t i " ttask
k tto:
– Enable or disable territory dimensions
— Enable only the dimensions you will use for your territory management
— Caveat: If you change the enabled dimensions, you must activate your changes before
they are available
– Enable assignment previews and territory validations
– Examine metrics used for forecasting
– Allow end users to update territories
• If user tterritory
it managementt iis enabled,
bl d managers can edit
dit the
th dimensions
di i off
subordinate territories and add customers
Add customers
• T it i d
Territories determine
t i visibility
i ibilit and
d access tto records
d
• Territories are defined by dimensions
• Use territory proposals to create or edit the territory hierarchy
• E l
Explore tterritory
it managementt
• Create a territory proposal
Territory Assignment
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Define assignment objects
• Describe territory-based assignment processing
• Administer territory-based assignment mappings
• Enable auxiliary dimensions
• Assigns
A i tterritories
it i tto:
– Customers (Contacts, Households, and Accounts)
– Leads
– Opportunity revenue lines
– Deals
• Uses mappings between attributes of the object to be assigned and the dimensions and
member values of a territory
• A i
Assignment
t Objects
Obj t
• Assignment Object Attributes
• Territory Assignment Mapping
More
• A representations
Are t ti off business
b i objects
bj t iinvolved
l d iin assignment
i t
– For example, leads or territories
• Are categorized into two types:
– Work objects are the objects that need something assigned to them
— As-delivered work objects are Account, Lead, Opportunity, and Revenue Line
– Candidate objects are the objects that are assigned to work objects
— As-delivered candidate objects are Territory and Resource
The Account work object is used for all customer assignment, including contacts and households.
The Resource candidate object is only used in rule-based assignment, which is covered in a
subsequent lesson.
Creating new assignment objects is beyond the scope of this course. Custom assignment objects
cannot be used with territory-based assignment, but must be used with rules-based assignment. For
more information on creating and working with custom assignment objects, consult the Assignment
Manager Resource Center (Doc ID #1522958.1) on My Oracle Support.
• A attributes
Are tt ib t off the
th assignment
i t object
bj t that
th t are usedd in
i determining
d t i i matches
t h
– A subset of the set of attributes for the original object
– For example, the opportunity business object has several dozen available fields,
while the opportunity assignment object has only around a dozen
• Are displayed in the Attributes tab for the assignment object
View Objects: When you create an Assignment Object, you specify a View Object to associate with
that assignment object. Once you have made this association, you specify which View Object
attributes will be used in the assignment mappings. View Objects exist for most objects in the
application; for example, leads, opportunities, accounts, deals, and so forth. Creating new View
Objects is beyond the scope of this course.
Diagnostic Display Attribute: This is the attribute that will be shown when assignment is run in
diagnostic mode. Typically you would set it to the same value as the View Object attribute, but in
certain cases,
cases such as an address
address, you might want to display the Sell To address rather than the
geography identifier, as the address is more human-readable.
• F territories,
For t it i assignment
i t compares territory
t it dimensions
di i to
t workk object
bj t attributes
tt ib t
– For example, examine the attributes of a lead, compare it to a territory's dimensions,
and if there is a match, assign the territory to the lead
– This is known as an assignment mapping
2. Assign territory
Territories
Assigned
Dimensions work object
• A dimension
di i mappingi identifies
id tifi one work k object
bj t attribute
tt ib t with
ith one di
dimensioni
– Used to match the work object attribute with the appropriate territory dimension
– For example, match the Organization Size attribute of the Lead work object with the
Customer Size dimension
• An attribute mapping identifies one work object attribute with one candidate object
attribute or dimension
– Used to match the work object attribute with the appropriate territory attribute or
territory dimension (geography or account)
– For example, for a partner territory confirm that the partner ID of the territory matches
the primary partner of the work object
• A literal mapping compares a candidate object attribute to a literal value
– Used to filter candidate territories
– For
F example, l ffor a partner mapping
i ensure that
h only
l partner territories
i i are considered
id d
Continued...
Matching candidates
are assigned
Territories
Literal mapping Attribute mapping excludes
excludes some candidates whose attributes
candidates immediately do not match work object's
• A sets
Are t off mappings
i that
th t determine
d t i how
h to
t assign
i territories
t it i to t workk objects
bj t
– Dimension mappings to match work object attributes to dimensions
– If necessary, attribute mappings to match candidate objects to work objects
– Literal mappings to determine when the mapping applies
• Are provided for all territory-based assignment objects
• Are designed
g to be used as-delivered with a minimum amount of configuration
g
• A workk object
bj t might
i ht h
have severall mapping
i sets
t ddefined
fi d
– Example: Sales Lead has:
— A territory mapping designed for assigning internal sales, overlay, and partner territories
— A separate mapping set for assigning territories with partner coverage
— A conditional attribute indicates when the mapping applies
— Additional mapping sets; for example, for simplified leads
• If multiple mapping sets apply
apply, all territories identified by all applicable mapping sets are
assigned
• F every provided
For id d mapping i set,t th
the di
dimensional
i l mappings
i are set:
t
– Active for all the predefined dimensions
– Inactive for the three auxiliary dimensions
– Exception: The Business Unit dimension for Revenue Line and Lead territory
assignment is inactive by default
• You must explicitly enable a mapping for each auxiliary dimension used in territory
management
– You may also deactivate mappings that you know you will never use
– This may provide a slight increase in performance
• A an implementer,
As i l t you must: t
– Enable the dimensions your company will use
— Discussed in a previous lesson
– Configure and enable any auxiliary dimensions your company will use
— Recall: You must have created a classification category for this dimension
• You may also be asked to
– Edit existing mapping sets, for example to:
— Disable an unused dimension mapping
— Add a literal mapping to reduce the scope of the mapping
– Set reporting and metrics options
– Create new mapping sets
— Beyond the scope of this course
More
1 Enable
1. E bl th
the di
dimension
i
2. Load and activate the new dimensions
3. Edit the territories to use the new dimension
4. Test the results
More
• N i t tto th
Navigate the "E
"Enable
bl Di
Dimension
i and
dMMetrics"
t i " page and
d enable
bl editing
diti
• Use the "Select and Add: Dimensions" dialog to add the auxiliary dimension
• Specify the classification category for the auxiliary dimension
• Once the
O th dimensions
di i and
d mappings
i are ready,
d lload
d and
d activate
ti t ththe di
dimension
i tto make
k
it available
• C t a tterritory
Create it proposall and
d specify
if values
l ffor th
the auxiliary
ili di
dimension
i
• Perform gap and overlap analysis
• Activate the proposal
• Create
C t multiple
lti l accounts,
t lleads,
d and/or
d/ opportunities
t iti andd verify
if that
th t assignment
i t iis
working as expected
• For dimensions
F di i th
thatt are nott in
i use, d
deactivating
ti ti th the mappings
i ffor th
thatt dimension
di i can
slightly improve performance
– Start the assignment object task and navigate to the mapping
• In each mapping, find mappings for that dimension and select the Inactive checkbox
• Save and Publish the changes
• While editing
Whil diti theth "E
"Enable
bl Dimensions
Di i and
d Metrics"
M t i " page, sett additional
dditi l options:
ti
– Enable the Territory Gap and Overlap Reports by selecting the "Enable territory
validations" option
— Enabled by default, disabling it provides a slight increase in performance at the cost of
being unable to run these reports
– Enable the Customer Assignment preview report by selecting the "Enable customer
g
assignment p
preview" option
p
— When these options are selected, Loading and Activating the changes also synchronizes
the geography and territory data to ensure these reports run correctly
– Allow users to edit territories by selecting "Enable Updates to Active Territories"
• Also add which metrics should be tracked for forecasting and territory reporting, as well
as how long to keep historical data
– For example, track the number of new customers at each period end date
• Provide
P id ttools
l tto d
determine
t i h how assignment
i t iis working:
ki
– Track progress, performance, and failure rates of assignments
– Quickly identify the transactions that are generating errors
– And so forth
• To perform assignment diagnostics:
– Run batch assignment in diagnostic mode
— Details are in the referenced document
– Review the resulting reports for:
— Step-by-step details on assignment processing
— Processing results for each record, along with reasons the record was assigned the way it
was
— Dimension-by-dimension analysis on which dimensions are most-used and which are
least-used
least used
Reference: For more information on diagnostic tools for assignment manager, see "Diagnostic Tools
for Assignment Manager" (Doc ID #1684020.1) on My Oracle Support.
• Use th
U these ttasks
k to
t manage the
th Oracle-supplied
O l li d assignment
i t object
bj t groups
– Manage Customer Center Assignment Objects:
— Territory or Partner Territory to Account (or Contact or Household)
– Manage Sales Assignment Manager Objects
— Territory to Revenue Line
— Resource to Opportunity
— Territory to Partner Account
– Manage Sales Lead Assignment Objects
— Territory and Resource to Sales Lead
— Territory and Resource to Deal
– Each group has an associated task
– For example, "Manage Customer Center Assignment Objects" for the Account
g
assignment object
j
Assigning Opportunities: Oracle Sales Cloud Assignment Manager assigns team members to
opportunities based on revenue lines, so the mapping you must manage is from territory to revenue,
not territory to opportunity.
• Keep in
K i mind
i d th
thatt address
dd d
data
t th
thatt iis lleveraged
d ffor tterritory-based
it b d assignment
i t mustt be
b
validated
– Review the lesson on geographies for more details
• For more information, consult the Assignment Manager Resource Center in My Oracle
Support (Doc ID 1522958.1)
– This document has information about the diagnostic tools and other useful
assignment
i t videos,
id notes
t & white
hit papers
• A i
Assignment
t objects
bj t d determine
t i h how candidate
did t objects
bj t are assigned
i d tto work
k objects
bj t
• Territory-based assignment assigns territories to work objects based on territory
dimensions using assignment mappings
• Enable all dimensions you will use in the application
• Enable auxiliary dimensions by assigning them classification
categories
g and editing
g assignment
g mappings
pp g
• E
Examine
i existing
i ti assignment
i t objects
bj t and
d mappings
i
• Examine and test an auxiliary dimension mapping
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Describe uses for rule-based assignment
• Create a rule set and assignment rules
• Your business
Y b i requirements
i t may iinclude
l d specifications
ifi ti th
thatt cannott b
be supported
t dbby
territory-based assignment
– For example, assign a resource based on total revenue, rather than customer size
• Your lead volume may require automated preprocessing of leads
– Score or rank leads based on provided information
– Assign high-value leads to users who can make the final determination as to whether
they are worth pursuing
• You may need to add filters to territory-based assignment
– For example, only assign territories to qualified leads
• All of these issues may be resolved using rule-based assignment
Using Auxiliary Dimensions: Recommended practice is to use auxiliary dimensions for territory
assignment whenever possible. However, recall that auxiliary dimensions must be associated with
classification categories, so in certain circumstances where using an auxiliary dimension is not
feasible (such as assigning resources based on total revenue), use rule-based assignment.
• Assigns
A i candidate
did t objects
bj t tto workk objects
bj t using
i expression-based
i b d rules
l
– Allows for assignment based on attributes other than those specified in territory
management
– For example, total opportunity revenue
• Includes functionality to score and classify work objects
– Scoring and classification may be done independently of assignment
– For example, score candidates and assign the "best candidate for the job"
– Update the work object by modifying field values
• Can also be combined with territory-based assignment to filter the territories returned by
territory-based assignment
– This functionality is only available for leads
• Requires the creation and maintenance of the rules in addition to managing the
assignment object attributes
References: "Setting Up Work Assignment" in Oracle Sales Cloud Implementing Sales, or the
Assignment Manager Resource Center page (Doc ID 1522958.1) on My Oracle Support.
Caveat: Accounts cannot be assigned using rule-based assignment.
• Available
A il bl assignment
i t modes
d are:
– Scoring: Compute a score based on satisfied conditions
– Classification: Assign a value to a field in the work object
– Matching: Assign one or more candidates that match specified conditions
More
• A available
Are il bl ffor:
– Leads
• Evaluate a set of conditions and calculate a final numeric score
– Stored in the Score field of the lead
Leads are work objects Scoring rules calculate a Each lead's Score field
f the
for h scoring
i rules
l totall score ffor each
h llead
d iis updated
d d withi h iits score
Scoring Rule
Score field: Leads include a Score field that is not displayed by default. If your business
requirements state that users must be able to see the scores for these objects, an application
configurator can expose the field using Application Composer.
• Business
B i challenge:
h ll L
Lead
d volume
l
– Your company receives thousands of leads a day
– Your staff cannot manually process this many leads in a timely manner
• Business solution: Score the leads for further processing
– Create a scoring rule that:
— Processes all unqualified leads
— Assigns a score based on available fields on the lead, such as account, budget amount,
budget status, deal size, or so forth
– Create a recurring job that runs this scoring rule daily
• Result: All unqualified leads will be automatically scored on a daily basis
• A available
Are il bl ffor:
– Leads: Rank and qualification
• Evaluate a set of conditions (including score) and update one or more fields based on
the results
Leads are work objects Classification rules evaluate Each lead has its
for the classification rules conditions on each lead fields updated
Cl
Classification
ifi ti R Rule
l
• Business
B i challenge:
h ll O
Once lleads
d hhave b
been scored,
d th
they mustt b
be evaluated
l t db based
d on
their scores
• Business solution: Add classification rules that rank and qualify each lead based on its
generated score, for example:
– If a lead's evaluated score is over 100, set the lead's Rank = Hot
— Users can query for Hot leads to find high-scoring leads
– If a lead's
l d' evaluated
l t d score is
i over 200,
200 qualify
lif the
th llead
d
— This will typically cause the lead to be assigned a territory and an owner, and the owner
can further work with the lead
– Create a recurring job that runs these classification rules daily
• Result: High-scoring leads will be ranked, and possibly qualified, without user
intervention
• A available
Are il bl ffor:
– Leads: Resources assigned to the lead
– Opportunities: Resources assigned to the opportunity
• Evaluate both the work and candidate objects to determine matches
– For example, score resources based on their experience with the product and the
account, and assign the highest-scoring resources to the lead
Matching
g Rule
or
• B i
Business challenge:
h ll N t every sales
Not l representative
t ti isi an expertt in
i every product
d t
• Business solution:
– Add matching rules that assign product experts to leads and opportunities
– Create a recurring job that runs these matching rules daily
• Result: Every lead or opportunity with a product will be assigned a product expert
Caveat: Rule-based assignment does not have the ability to navigate the product hierarchy when
processing rules. You must specify the specific product when creating rules that assign such
experts.
• Profile
P fil options
ti d
determine
t i when
h automated
t t d assignment
i t occurs
– For example, accounts have both auto-assign on create and auto-assign on update
profile options
— These options only run territory-based assignment, not rules-based assignment
– For opportunities, a single profile option determines assignment behavior
— Profile Display Name = Assignment Submission at Save Enabled
— Profile Option Code = MOO
MOO_OPTY_ENABLE_AUTO_ASGN
OPTY ENABLE AUTO ASGN
— This option runs both territory-based and rule-based assignment
Reference: For a complete list of when automated assignment occurs, consult "Setting Up Work
Assignments" in Oracle Sales Cloud Implementing Sales.
You will explore running batch assignment in the practice.
More
Increase the
Action
score by 10
• Example: R l 1
Rule
– If the Budget Amount >= $1M and < $5M,
increase the score by 10 Rule 2
– If the Budget Amount >= $5M,
increase the score by 25 Rule 3
– If the Budget Status = Approved,
increase the score by 20
• I a grouping
Is i off rule
l sets
t
• Is used to:
– Determine which rule sets should be run for an object in a particular situation
— For example, for rule-based assignment of resources to opportunities, use this rule
category
– Determine which rule sets should be run during batch processing
— E
Every process takes
t k a rule
l category
t as an input
i t argumentt
Rule Set = Budget Scoring Rule Set = Budget Qualification Rule Set = Budget Assignment Rule
Category
Continued...
• The as-delivered
Th d li d application
li ti iincludes
l d predefined
d fi d rule
l categories
t i ffor mostt assignment
i t
object types, for example:
– The Revenue Territory Default Rule Category is used to filter territories returned by
territory-based assignment
— Only relevant when using territory-based assignment plus rule filtering for revenue lines
– The Sales Team Member Recommendation Default Rule Category is the rule
category for rules that assign sales team members to opportunities
• If necessary, use the appropriate "Manage Assignment Objects" task to create additional
rule categories
– For example, use "Manage Sales Assignment Manager Objects" to create custom
rule categories for opportunities
1 Design
1. D i ththe rule
l
2. Edit profile options to enable rule-based assignment for the object
3. (Optional) Create custom rule categories for the desired assignment modes
4. Create each rule set and associate it with its rule category
5. Add rules to each rule set
6. Schedule rule-based assignment
7. Test the rules
Example: Add one rule set that scores a lead based on its attributes, and a second rule set
that sets lead rank based on that score
More
• Determine
D t i whether
h th tterritory-based
it b d assignment
i t will
ill satisfy
ti f your requirements
i t
– Territory-based assignment is more efficient and easier to maintain than rule-based
assignment
• Decide on a minimal set of rules to implement the requirement
• Determine a set of rule sets to contain these rules
– Do you need one rule set? Two? More?
• Determine which rule category should contain each rule set
• Determine which batch processes you will need to run, and how often each should run
Tasks: Use "Manage Opportunity Profile Options" to manage Opportunity assignment. Use "Manage
Sales Lead Profile Options" to manage sales lead assignment types.
Options:
• For leads:
- Profile Option Name = Lead Assignment Mode
- Profile Option Code = MKL_LEAD_DEFAULT_ASGN_MODE
- Default Value = Territory
Territory-based
based Assignment Only
• For opportunities:
- Profile Option Name = Opportunity Assignment Mode
- Profile Option Code = MOO_OPTY_DEFAULT_ASGN_MODE
- Default Value = Territory-based Assignment Only
• For deals:
- Profile Option Name = Deal Registration Assignment Mode
- Profile Option Code = MKL_DEAL_DEFAULT_ASGN_MODE
- Default Value = Territory-based Assignment Only
• U th
Use the rule
l managementt ttaskk tto select
l t a category
t and
d create
t a rule
l sett
Select a category
Tasks: Use the "Manage Sales Assignment Manager Rules" task to manage assignments for
opportunities and revenue lines. Use the "Manage Sales Lead Assignment Rules" task to manage
assignments for leads and deals.
• Add rules
l and
d logic
l i tot determine
d t i a score, select
l t a candidate,
did t or so forth
f th
Continued...
Spaces in Names: It is permissible to have spaces in rule names, rule set names, and rule set
category names.
• R l iin non-scoring
Rules i rule
l sets
t can use score as a condition
diti
The RuleCold rule is a classification
rule in the Lead_Ranking_Rule rule set
• Schedule
S h d l th
the appropriate
i t assignment
i t process
– For example, the "Manage Lead Processing Activities" task allows you to schedule
lead assignment jobs
— You must schedule a separate job for each assignment type
— For example, one job for scoring, then one job for ranking
• Create
C t a record,
d sett fields,
fi ld andd verify
if th
the rule
l iis b
behaving
h i as expected:
t d
– The record is assigned the correct territory or resources
– The record is given the correct score
– Or so forth
• Rule-based
R l b d assignment
i t provides
id an alternative
lt ti tto tterritory-based
it b d assignment
i t
– Assign resources based on non-dimension fields
– Score records and perform score-based assignments
– And so forth
• Rules perform an action based on conditions
– Increase a score, perform an assignment, or so forth
• Rule sets are logical groupings of rules
• Rule categories are groupings of rule sets
• C fi
Configure a rule
l tto assign
i a resource
• Run batch assignment to test the new rule
Forecasting
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Describe sales forecasting
• Configure forecasting
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• I method
Is th d off providing
idi predictions
di ti off future
f t revenue for
f specific
ifi ti
time periods
i d
• Is automatically generated from opportunities
– Sales representatives do not need to re-enter any data
• Includes won opportunities in a territory when close dates fall within the forecast period
• Include other opportunities based on specified criteria
– Users may manually include or exclude specific opportunities
• Is not configured in the as-delivered application
• O
Opportunity
t it isi created
t d
• Opportunity meets forecast criteria
• Opportunity close date is within the forecast period
• Opportunity includes revenue lines
• Assignment is run
• Opportunity revenue line gets assigned to the appropriate forecast territory
• Forecast item is generated and appears in the forecast
• Forecast rolls up the territory hierarchy
• Territory owner sees all revenue lines credited directly to their forecast territory
• Territory owner sees all revenue lines rolling indirectly up the territory hierarchy
• Sales
S l representatives
t ti can:
– View forecasts for his or her territory
– View and compare forecasts to key
metrics such as pipeline and won
revenue
– View changes since the last forecast
– Review items that are included in the
forecast
– Drill into opportunities to update the
opportunity and the forecast
– View opportunities not included in the
forecast
– Submit the forecast for managerg
review
Pipeline is the total opportunity revenue amount of all product lines where the Status category is
Open, the primary territory is the target territory, and the close date is within in the forecast period.
• IIn addition
dditi tot sales
l representative
t ti
functionality, sales managers can:
– View a subordinate’s forecast and
submit or reject it
– See submission status
– View and adjust forecast values at
an item level
– View and make summary level
adjustments by product lines
• A
Accounting
ti calendar
l d mustt b
be configured
fi d
• Territories must be configured
– Forecasting rolls up the territory hierarchy not the resource hierarchy
• Territories must be assigned to opportunities
More
• D fi
Defines ti
time period
i d ffor th
the fforecastt
• Can be for a Quarter, Year, or the Fiscal period that was defined in the accounting
calendar
– Is typically configured for a Quarter
• Defines
D fi th
the period
i d off ti
time where:
h
– Sales representatives can update and submit their forecasts
– Managers can adjust forecasts
• Can be at any point in the forecast depending on business requirements
• Forecast frequency defines how many submission windows are allowed per forecast
– Example: For a quarterly forecast you may have a monthly forecasting call so you
would define three submission windows and conduct the call after the forecasts have
been submitted
The start of the submission window is called the Territory Freeze Date. Any sales territory changes
after this date are ignored and applied to subsequent forecasting windows.
The end of the submission window is called the First Forecast Due Date. The application takes a
forecast snapshot at the end of the day.
• I a setting
Is tti tto ddetermine
t i which
hi h opportunities
t iti gett iincluded
l d d iin a fforecastt
– Enter the probability that matches the default probability of the appropriate sales
stage in your sales method
– For example, if you want all opportunities in the Agreement sales stage or in a later
sales stage to be included, and the default win probability is 70 percent for that stage,
you would enter 70
Opportunity win
probability to include in
the forecast
• Allows sales
All l representatives
t ti or their
th i managers to
t include
i l d or exclude
l d an opportunity
t it ffrom
a forecast regardless of its win probability
• All
Allows forecast
f t adjustments
dj t t by
b product
d t rather
th than
th territories
t it i
• Includes a hierarchy depth which specifies the number of sales catalog levels
– Recommendation is to only use one
If you enable this option you may also enable the ORA_QUANTITY lookup code to allow
adjustments by product quantity in addition to revenue:
• Lookup Type = ORA_ZSF_SHOW_METRICS
• Lookup Meaning = Forecast metrics options
• Lookup Code = ORA_QUANTITY
• S t Forecasting
Set F ti Options
O ti
• Schedule Forecast Processes
More
• Use th
U the "S
"Select
l tFForecasting
ti Options"
O ti "
task to define:
– Forecast Period Parameters
— Defines forecast dates
– Unadjusted Forecast Criteria
— Controls what is included in the
forecast
– Enable Forecasting by Product
Continued...
– Review
R i th
the fforecastt periods
i d and
d make
k any adjustments
dj t t
• Once forecast
O f t options
ti are submitted,
b itt d schedule
h d l processes tto run periodically
i di ll
– Either search for processes directly or find them in the "Define Sales Forecasting
Configuration" task
• Due Date Check
– Archives forecasts that are past their due dates and activates the next scheduled
forecast
– Schedule
S h d l tto run daily
d il after
ft midnight
id i ht
• Refresh Forecast
– Updates current and future forecasts using the latest opportunity data
– Updates the forecast territory hierarchy from the latest active territories
– Schedule to run once prior to the territory freeze date for each forecast period
Continued...
• Refresh
R f hF Forecastt Items
It
– Refreshes forecast items that may not be synchronized with the underlying
opportunity data
– Schedule to run daily after midnight
• Compress Forecast Metrics
– Reduces space usage and improves performance by compressing pre calculated
metrics
ti
– Schedule to run every 10 minutes
• Refresh Revenue Metrics
– Refreshes the pipeline metrics visible to the manager
– If either the pipeline metric or the closed revenue metric have been enabled,
schedule to run every 10 minutes
• Opportunity
O t it profile
fil options
ti also
l h help
l control
t l what
h t gets
t included
i l d d iin a fforecast:
t
– Configure sales methods to require the Win Probability Fields and Close Date in later
sales stages
– Configure opportunities to assign territories when they are saved so that they are
always associated with a sales territory
– Opportunity profile options are covered in a separate lesson
• F
Forecasting
ti provides
id predictions
di ti off ffuture
t sales
l
• You must configure forecasting by configuring options and scheduling processes
• Forecasting is dependent on territories being defined
• E l
Explore fforecasting
ti options
ti
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Define Oracle Sales Cloud extensibility
• Identify the extensibility tools available for Oracle Sales Cloud
• Identify some customizations that are available
• Explain the purpose and use of sandboxes
• Sandboxes
• Application Composer
Geographies Sales Assessments • Page Composer
Catalog • BI Composer
• Business Process Composer
p
Reference http://docs.oracle.com/cloud/latest/salescs_gs/FASMC/toc.htm
• I the
Is th ability
bilit to
t add
dd ffunctionality
ti lit to
t the
th base
b Oracle
O l Sales
S l Cloud
Cl d (OSC) application
li ti
• For example, you can:
– Create new page layouts
– Create new processes or workflows
– Add fields to existing business objects or create new objects
– Integrate OSC with other systems
• Oracle
O l Application
A li ti C Composer
– Is used to modify business objects, business logic, and object pages
– Is the focus of this lesson
• Other extensibility tools
– Oracle Page Composer is used for some page customizations
— For example, the default order of columns shown on a landing page and which columns
are shown
– Oracle BI Composer Is used to create custom reports and dashboards
– Oracle Process Composer Is used to create or edit approval process flows
This lesson focuses only on the Oracle Application Composer tool. More information on other
available extensibility tools can be obtained from the Oracle Help Center (docs.oracle.com) > Cloud
> Applications > Sales > Customize.
• I an extensibility
Is t ibilit ttooll used
d iin OSC tto modify
dif bbusiness
i objects
bj t and
dbbusiness
i llogic
i
• Includes a set of wizards to simplify, and in some cases eliminate, coding
• Can be used to:
– Customize standard business objects and pages
– Create new custom objects and pages for them
– Manage custom object security
– Manage object relationships
– Create business object workflows
– Create global functions
– And so forth
More
• Customizations
C t i ti th
thatt can be
b usedd ffor supported
t d standard
t d d objects
bj t iinclude:
l d
– Adding custom fields to the object
– Modifying the object pages, for example:
— Showing or hiding fields, including custom fields
— Making fields required or read-only
— Adding business logic to determine when a field is editable
— And so forth
– Adding action buttons and/or links to the object pages
– Writing validation or trigger scripts for the object
Dynamic Layouts: Oracle Application Composer allows you to create multiple layouts for a page,
based on criteria such as user role, record type, or an advanced expression.
There is no fixed limit on the number of custom objects that you can create.
• For custom
F t objects
bj t only
l (not
( t standard
t d d objects),
bj t ) security
it iis sett and
d managed
d within
ithi
Oracle Application Composer
– You must select:
— Which custom roles are allowed to access the object
— Which type of access (Create/View/Update/Delete) is allowed for each role
• By default, all custom objects are accessible from the "Custom Objects Administration"
role
– Other custom roles can be added to custom objects as necessary
– Seeded roles cannot be modified, and therefore cannot be associated with custom
objects
• B th standard
Both t d d and
d custom
t objects
bj t can be
b associated
i t d in
i relationships
l ti hi
• Types of relationships:
– One-to-many (1:M)
— For example, if an account can have multiple associated events, but each event is
specific to that account only, create a 1:M relationship
— To expose a list of events associated with a specific account as a subtab on the account
details page
page, you must first create a one-to-many
one to many relationship between the account and
event objects
– Many-to-many (M:M)
— For example, if an event might involve multiple accounts, you would create a M:M
relationship between accounts and events
— In this case, one account could be associated with many events, and many accounts
could be associated with a single event
• Objectt workflows
Obj kfl run when
h specific ifi conditions
diti are met,
t such
h as:
– A certain field or set of fields is changed
– The new values of the field or fields match some criteria
• Object workflows invoke one or more actions, such as:
– Updating fields within the object
– Sending an e-mail notification to specified recipients
– Generating one or more tasks
– Sending an outbound message to a web service endpoint
– Invoking a business process flow
• Global
Gl b l ffunctions
ti
– Can be used for any object
– Are written in the Groovy scripting language
• For example:
– A utility function that defines standard helper routines to log the start of a block of
groovy script and to log a diagnostic message
– A utility function that simplifies the creation of the most common search criteria for a
given object
• Visibility
Vi ibilit off Ch
Changes
– During development, changes should not be visible to other users until modifications
have been tested and finalized
• Collisions
– Multiple configurators may be performing customizations simultaneously
– Changes made by one configurator may conflict with or overwrite changes by another
Possible collision when
attempting to save
changes
• Are used
A d tto mitigate
iti t (th
(though
h nott entirely
ti l prevent)
t) visibility
i ibilit and
d collision
lli i iissues with
ith
customizations
• Are static snapshots (temporary copies) of portions of the application
• Should be assigned individually to a single configurator as a workspace
– Provide isolated environments for design and testing without exposing changes to
end users or other configurators
Sandbox #1 used
by Configurator
#1 to work on one
or more objects
Sandbox #2 used
by Configurator
#2 to work on a
different group of
objects
There are some modifications, such as editing business processes, which must be made in the
mainline.
Although it is possible for two configurators to work in the same sandbox, that defeats the purpose of
sandboxes and is not recommended.
• Sandboxes
S db mustt b
be activated
ti t d iin order
d tto b
be usedd
– Activation ensures that all customizations made by the configurator are stored in the
active sandbox
• The configurator can activate/deactivate a sandbox
– The currently active sandbox is indicated in the user interface (UI) of the configurator
– Each configurator can have only one active sandbox at a time
• Moves the
M th modifications
difi ti maded iin a sandbox
db iinto
t th
the mainline
i li (th
(the main
i code),
d ) so th
they
take effect and are visible to all users
– A sandbox may be discarded rather than published and changes made in it will be
lost
– Some changes, such as creating a new record, are made in the database itself, so
they will remain after you delete the sandbox
• Is done only after development is complete and tested
• WARNING
– Publishing affects all users of the application and also other configurators
— When you publish, all other configurators' sandboxes become "stale" (because they
contain outdated code) and invalid
— If a stale sandbox is published, it can corrupt the application
— A configurator who tries to publish a stale sandbox will be warned by the application and
should not override that warning
– ALWAYS follow your company's practices and procedures in this area
Copyright © 2017, Oracle and/or its affiliates. All rights reserved.
• Never work
N k iin th
the mainline,
i li only
l iin a sandbox
db
– This does not apply to certain tasks such as custom processes, which must be
modified in the mainline
• Always provide each individual configurator with their own sandbox
– The application does not automatically ensure that two configurators are not in the
same sandbox, so you must provide policies to make sure this is done
• Never override sandbox warnings
– The application will warn a configurator who attempts to publish a "stale" sandbox
– To override this warning is very risky and can damage the application itself
– Establish policies to avoid this
• Even when working in a sandbox, transactional data such as records that are changed
will be stored in the actual database, will be visible to all users, and will continue to exist
even if the sandbox is deleted
• This lesson
Thi l provided
id d a hi
high-level
hl l overview
i off th
the capabilities
biliti off O
Oracle
l AApplication
li ti
Composer
• More information is available from
– Oracle Fusion Applications Documentation: Oracle Sales Cloud Extending Sales
Guide
– Oracle University's course on extending Oracle Sales Cloud
• Oracle
O l Sales
S l Cl
Cloud
d provides
id extensibility
t ibilit ttools:
l
– Oracle Page Composer is used to change the look-and-feel of pages
– Oracle BI Composer can create new reports and analyses
– Oracle Process Composer creates approval processes
– Oracle Application Composer allows you to:
— Customize existing business objects or create your own
— Manage relationships between objects
— Determine which fields are displayed for an object and properties of those fields
— For example, whether or not a field is read-only
— Create object workflows that are triggered when specified fields are set to
specified values
• Sandboxes are used to isolate configurators who are working on
customizations so their work does not interfere with each other,, and
so their work is not visible to other users until it is completed and
tested
Copyright © 2017, Oracle and/or its affiliates. All rights reserved.
Migration
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Identify the migration tools available to you in Oracle Sales Cloud
• Use these migration tools to migrate from one Oracle Sales Cloud instance to another
• Oracle
O l provides
id you withith a ttestt iinstance
t tto th
thoroughly
hl test
t t allll off your configurations
fi ti and
d
customizations before deployment
• Once testing is complete, you must migrate these changes from the test environment to
the production environment
– This is what this lesson refers to as "migration"
– This lesson does not discuss upgrades; that is, upgrading from one Oracle Sales
Cl d release
Cloud l tto another
th
• Migration may include:
– Setup data, such as calendars, geographies, and custom security roles
– Configuration data, such as users, lookups, and classification categories
– Transactional data, such as contacts, and accounts
– Customizations made using Application Composer or Page Composer
• Oracle
O l Sales
S l Cl Cloud
d provides
id migration
i ti ttools
l ffor migrating
i ti d data
t ffrom ttestt tto production:
d ti
– Functional Setup Manager (FSM) on the Setup and Maintenance page migrates
setup data
— For example, jobs, resource roles, product groups, and so forth
– Customization Set Migration migrates customizations made in many areas:
— Customizations made using Application Composer and Page Composer
— Customizations made in other Oracle Fusion applications
– File-based import and export migrates transactional or user configuration data you
worked with in the test system
— Users
— Accounts
— Opportunities
— Leads
— And so forth
Continued...
– Territory management migrates your territory hierarchy
Copyright © 2017, Oracle and/or its affiliates. All rights reserved.
Both functional setup manager and customization set migration migrate lookups. In general when
there is overlap you should use customization set migration.
• U th
Use these migration
i ti ttools
l tto migrate
i t ffrom ttestt to
t production
d ti
• Before
B f you start
t t your migration,
i ti plan
l and d prepare:
– What functional setup tasks did you run to set up the test environment?
– What customizations have you made in the test environment?
– What data from the test environment will you migrate?
— Users
— Transactional data such as accounts, contacts, leads, and opportunities
— T it i
Territories
— And so forth
• Ask yourself, "What have I changed?"
– This is a good first question, and careful documentation of changes can greatly
facilitate migration
– Documenting your changes from the very start of your project is far easier than trying
to find all of the changes after the fact
• Ch k th
Check the Getting
G tti StStarted
t d Guide
G id to
t be
b sure your iimplementation
l t ti iis complete
l t
• Make sure the production environment is in its initially-provisioned state with the default
settings
– Verify the initially-provisioned values are set correctly
• Make sure all customizations you want to capture in the migration have been published
• Verify both environments are on the same release and the same patch bundle
• Verify that your migration user has to appropriate security roles
• Migrates:
Mi t
– Company profile information
– Jobs and resource roles
– File import mappings
– Currencies and accounting calendars
– Lookups
— Caveat: Recommended practice is to use Customization Set Migration to migrate lookups
– And more
• Does not migrate:
– Geography structures and data
– Territories
– User-entered data
– Security customizations
• I th
In the test
t t system,
t use Functional
F ti l Setup
S t Manager
M to
t exportt your implementation
i l t ti project
j t
– Exclude Manage Standard Lookups and Manage Common Lookups because
Customization Migration migrates them
• In the production system, use Functional Setup manager to import this implementation
project
– Most of the project's configurations will be applied to the production system
• Perform post-migration configuration
– All profile options must be manually configured
– Schedule Enterprise Scheduling Service jobs
— For example, forecasting jobs
– Tasks not included by FSM
References:
• The YouTube video https://www.youtube.com/watch?v=Mthtv4_OFF0 is "Performing
Offering-Based Imports", and provides the steps to import setup tasks and monitor the import.
• The YouTube video https://www.youtube.com/watch?v=AFK0O1QqfmQ is "Specifying
Offering-Based Import Options", and describes how to identify data discrepancies after the
import.
• Migrates:
Mi t
– Most customizations made using Oracle Application Composer, including custom
object security
– Customizations made using Oracle Page Composer and the Structure page
– Messages and lookups
– Data security
– Business
B i i t lli
intelligence content
t t
– Scheduled processes
– And so forth
• Does not migrate:
– Import/export artifacts in Oracle Application Composer
– Web service credential information
– Personalizations
Reference: Refer to Oracle Sales Cloud Customizing Sales for a list of customizations that are and
are not migrated.
If a customization can be migrated by both FSM and Customization Migration, recommended
practice is to use Customization Migration.
Customization migration also does not migrate sales prediction rules and customizations for
Incentive Compensation.
• O the
On th source system:
t
– Warn developers not to publish changes to the mainline during migration
— Changes to the mainline that occur during the export process may corrupt the export
– Create a “Customization Set” in the application
– Download the customization set to a local file system
• On the destination system:
– Upload the customization set to the application
– Check for conflicts
– Apply the customizations
1 Stop
1. St mainline
i li modifications
difi ti during
d i migration
i ti
2. Create a customization set
3. Download the customization set
4. Upload the customization set
5. Apply the customizations
6. Perform post-import work
More
• To avoid
T id any potential
t ti l conflicts
fli t or race conditions,
diti no changes
h t the
to th mainline
i li should
h ld
occur during the export process
– Do not publish sandboxes
– Do not make changes directly to the mainline
— This also violates development best practices
• Sandboxes are not exported, so developers can continue to work in them
Stop mainline
changes during export
Race conditions: When two or more processes are trying to access a shared resource at the same
time this is known as a "race condition" as the processes vie for the resource. If any of the processes
perform write operations, the other processes might end up reading partially-written data, leading to
corruption issues.
Ceasing publication: As of Release 8, Customization Migration does not lock the MDS layer when
exporting data, so it is possible that a developer publishing a sandbox or performing mainline
customizations while the data is being generated could create a race condition and corrupt the data.
Therefore best practice is to notify all developers before generating the customization set.
Therefore, set
• On the
O th source system,
t navigate
i t tot the
th Customization
C t i ti Mi Migration
ti page and
d create
t a
customization set
– You must exit your sandbox to perform this step
– Specify a customization set name and, optionally, a description
Navigation: Access the Customization Migration page using Tools > Migration. You need the
FND_APPLICATION_ADMINISTRATOR_JOB role to access this page.
The Customization Migration page is not shown because it is very simple. The Outgoing tab has a
single button: "Create Customization Set". The Incoming tab will be shown on subsequent slides.
Customization Types: This area currently lists the customization types that will be exported, and is
not editable. Mouse over an entry to see details. Specifying exactly which customization types to
export is on the product roadmap.
• Waitit for
W f the
th customization
t i ti sett tot be
b completedl t d before
b f allowing
ll i developers
d l tto start
t t
performing customizations again
– Use the Refresh button to monitor its progress
• Review the log file for warnings and error messages
• Once the
O th process has
h completed,
l t d download
d l d the
th customization
t i ti sett tto didiskk
– The Delete button deletes the customization set from the server
— The log and a record that the set was created remain
– Once you have successfully downloaded the customization set, delete it to avoid it
taking up unnecessary space on the server
Download the
customization set
Save it locally
• O the
On th destination
d ti ti system: t
– Delete any obsolete customization sets
– Navigate to the Incoming tab of the Customization Migration page and select a
customization set
Select Incoming
Select the
customization set
• M k sure no O
Make Oracle
l EEnterprise
t i S Scheduler
h d l jjobs
b are running
i or scheduled
h d l d to
t run
• Make sure no other users are logged in to the application
• Click Apply to apply the customizations
– Once the import is complete and tested, compact the customization set
• If an error occurs, the process stops and removes changes
Apply the
customization set
Errors: If errors are encountered during the import process, all changes are automatically rolled
back, reverting the target to the state prior to import.
• Manually
M ll create
t any unsupported
t d customizations
t i ti on the
th target
t t
– For example, create import/export artifacts or register web services for Groovy
scripting
• Customization
C t i ti Mi Migration
ti supportst "b
"backing
ki out" t" off an iimportt
– Restores system to customization level just before import
– Only the last imported customization set can be restored
— You cannot recursively "back out" to get to previous sets
Caveat: User personalizations performed after a customization set is applied are lost if you restore
(back out of) that customization set.
• From the
F th Territory
T it Management
M t area in
i Sales
S l Cloud,
Cl d you can export/import
t/i t your tterritory
it
definition
– Caveat: You must load your geography data in the target environment before
migrating your territory definition
• Use fil
U file-based
b d iimport/export
t/ t to
t migrate
i t any other
th transactional
t ti l data
d t
– Opportunities
– Leads
– And so forth
• Functional
F ti l and
dDData
t SSecurity
it C
Customization
t i ti reportt shows h diff
differences b
between
t
predefined security role model and security artifacts in the environment
• If necessary, update the test plans for the production environment, then run them
• Migrate BI Stuff
– Set Disable BI For Customization Set Migration profile option to "No"
– Run user sync
y process
p
• B th environments
Both i t ((source and
d ttarget)
t) mustt be
b on the
th same release
l
• Be aware that FSM and Customization Migration have some overlap
– For example, lookups
– Try to use Customization Migration for all such overlap
• Use sandboxes for all development
– This prevents in
in-progress
progress work from being exported using Customization Manager
• Do not modify the mainline in the source during export
– For example, do not publish a sandbox
Continued...
Same release: Keep in mind that for Oracle Sales Cloud customer, there may be up to a
2-week delay between the patch of the development environment and the patch of the production
environment. Therefore, it is critical to check the release and patch number on both systems when
performing the export and import.
Overlapping data: Recommended practice is to use Customization Migration to perform any
customizations that overlap with FSM; for example, lookups. Do not manually perform setup tasks in
Functional Setup Manager that will be migrated in a customization set.
• D nott modify
Do dif th
the exported
t d customization
t i ti fil files
• Be sure that there are no Oracle Enterprise Scheduler jobs running or scheduled to run
during the import
• Be sure that no other users are logged on during the import
• Tools
T l ffor migrating
i ti application
li ti metadata
t d t include
i l d F Functional
ti lSSetup
t M Manager (FSM) and d
Customization Migration
– FSM does not involve customizations created using Oracle Application Composer or
Oracle Page Composer
– Customization Manager is for migrating customizations
• To migrate customizations using Customization Manager:
– Create a customization set on the source system and download it
– Upload the customization set to the target system and apply it
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Identify available Oracle Sales Cloud (OSC) integrations with other Oracle products
• Identify other available integration mechanisms
• You have
Y h many options
ti when
h it comes tto iintegrations
t ti
– Prebuilt
– Platform services (PaaS)
– Partner solutions (Cloud Marketplace)
– Web Services
More
• Oracle
O l provides
id prebuilt
b ilt integrations
i t ti
between OSC and other Oracle
products such as:
– Service Cloud
– Configure, Price, and Quote (CPQ)
– E-Business Suite
– Siebel
Si b l CRM
– And so on
• For details consult the Integrate section
of the Oracle Sales Cloud Help Center
– Use the integration guides
provided there to perform your
integrations
• O l provides
Oracle id robust
b t platform
l tf services
i tto h
help
l you iintegrate
t t
• Refer to cloud.oracle.com under Platform for the latest information and trials
Of particular note is Oracle Integration Cloud Service (ICS) which provides a Visual Integration
Designer to allow you to drag and drop to develop your integrations with zero coding.
• O l provides
Oracle id a network
t k off partner
t applications
li ti and
d services
i tto meett your needs
d
• Refer to cloud.oracle.com/marketplace
Cloud Marketplace
http://docs.oracle.com/cloud/latest/salescs_gs/salescs_integrate.htm
Reminder for bulk data you should use File-Based Import not Web Services.
• O l Sales
Oracle S l Cl
Cloud
d has
h many integration
i t ti options
ti
Access Levels
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Describe access level functionality in Oracle Sales Cloud
• I a security
Is it mechanism
h i th
thatt augmentst role-based
l b d access control
t l (RBAC)
– First apply RBAC, then apply visibility
• Controls access levels to records:
– Read-only, read/write, or full access
– Only users with full access can grant/remove access to other users
• Users are associated with territories that are assigned
g to individual records
– A user's access to records is therefore determined by his or her territory or territories
– Specific access varies depending on the record type
Visibility is also controlled for partners. Partner management is the topic of a separate course, so
partner assignment will not be discussed here. It is similar to Team assignment, but assigns partners
rather than employees.
• When a record
Wh d iis created,
t d it h
has an owner
– The owner always has access to the record, assuming RBAC permits it
• Once a record is assigned, it has territories
– Territories have associated users, who now have access to the record
• Team members may be manually or automatically added to the record
– The owner is a team member
• Managers of owners and team members have access to the record
• Members of higher-level territories have access to the record
• I O
In Oracle
l Sales
S l ClCloud,
d every access-controlled
t ll d recorddhhas ffour access llevels:
l
– No access: The user cannot see the record
– View only: The user can see the record, but cannot change it
– Edit: The user can perform all actions on the record except adding or removing other
users
— This includes sharing the record on Oracle Social Network, deleting the record, running
assignment on the record
record, and so forth
– Full: The user can grant and remove access to other users
View Only No Access
Edit User 1
User 4
Full Access
User 6
Record User 5
User 8 User 2
User 7
Administrators User 3
More
No Access: Note that for some objects, the "No Access" level is not implemented in the as-delivered
application. For example, Contacts and Accounts are visible to all sales users, hence do not have a
"No Access" level.
• Members
M b with
ith "f
"fullll access"" h
have full
f ll access tto records
d as granted
t dbby th
their
i security
it roles
l
– Visibility, read/write access, add/remove other users, and so forth
• Full access is granted to:
– Record owners
— Typically the user who created the record, but ownership can be reassigned
– Owners of territories assigned to the record
– Managers of owners
— Both territory-based and organization-based management hierarchies
– Administrators
– Other users, depending on the record type
Full Access
• IIn th
the Advanced
Ad dSSearch h panel,l ffour record
d sets
t return
t records
d ffor which
hi h you hhave F
Fullll
Access:
– I own: Records for which you are the owner
– My territory: Records for which you own a territory assigned to the record
– My subordinates own: Records for which you manage the owner
– My territory hierarchy: Records for which you manage the owner's territory
Advanced Search Panel: To open the Advanced Search panel for an object (for example,
Accounts), navigate to the landing page for the object, then, to the right of the List field, click the
Show Advanced Search icon.
• Members
M b with
ith "edit
" dit access"" h
have ffullll access tto records
d as granted
t dbby th
their
i security
it
roles, except:
– They cannot add/remove other users
• Edit access is typically granted to:
– Members of territories assigned to the record
– Users manually added to the record team
– Managers of users with edit access
• Whether users get full or edit access depends on the record type
Edit
Full Access John Smith User added manually
• IIn th
the Advanced
Ad dS
Search
h panel,l ffour recordd sets
t return
t records
d ffor which
hi h you h
have Edit
Access:
– I am on the team: Records for which you are on the team
– My subordinates are on the team: Records for which you manage team members
– I am on the team or territory: Both team and territory membership are shown
– My subordinates are on the team or territory: Records for which you manage team or
territory members
Caveat: Your access level depends on the record type and your position on the team. These filters
show all records for which you have either edit or full access. So they should be considered, "Filters
that provide me at least edit access to records".
• Some record
S d ttypes allow
ll allll users tto see th
the records
d
– Contacts, Households, Accounts
• Other record types have restricted access: You must have team membership to see the
record
– Leads, Opportunities
• For records where yyou are not an owner or on the team, but that still grant
g yyou visibility,
y
you have View access
– Read-only access to the record
View Only
Edit
Full Access
John Smith All users have view
Record Joe User
Lisa Jones access to accounts
Jane Jones
Administrators
• IIn th
the Advanced
Ad dSSearch
h panel,l use the
th "All records
d I can see"" record
d sett to
t see allll
records to which you have access
• Caveats:
– You must provide search criteria when using this record set
— Typically at least 3 letters of the record name
– Using search criteria that are not specific enough might lead to poor performance
• A
Account,
t Contact,
C t t or Household
H h ld
• Lead or Opportunity
More
• F accounts,
For t contacts,
t t and d households:
h h ld
– All users have View access
— They do not need to be associated with the record in order to see it
– Manually added team members have Edit access
— Members with Full access can change members' access levels
– Owners and all territory members have Full access
• F opportunities
For t iti and d lleads:
d
– Users not associated with the lead or opportunity do not have access
– Manually added team members have Edit access
— Members with Full access can change members' access levels
– Owners and all territory members have Full access
– If an account is associated with the lead or opportunity, account members gain View
access to that lead or opport
opportunity
nit
— This extends to territory access: Account territory team members have access to the
opportunity
— This also extends to the organization and territory hierarchies: An account team member's
manager has access to the opportunity
• The four
Th f access levels
l l available
il bl iin O
Oracle
l S
Sales
l Cl
Cloudd are:
– Full access: User can edit record and add/remove/change permissions for other
users
– Edit access: User can edit record, but cannot modify other users' access
– View access: User has read-only access to the record
– No access: User cannot see the record
• The access level for a user depends on:
– Ownership
– Territory membership
– Team membership
– Territory and organization hierarchy
Sandboxes
Aft completing
After l ti thi
this llesson, you should
h ld bbe able
bl tto:
• Describe how sandboxes work in Oracle Sales Cloud
• Create and manage sandboxes
• Work with sandboxes safely
• Withoutt working
With ki very carefully,
f ll developers
d l or administrators
d i i t t making
ki modifications
difi ti can
cause many issues:
– Two people trying to modify the same object at the same time would generate a
conflict
– Design time at runtime = Users see modifications as they are made, rather than after
they have been reviewed and tested
• Developers and administrators need an isolated environment where they can design
design,
test, and review their modifications without exposing them to users
• Oracle Sales Cloud provides "sandboxes" to allow developers and administrators to test
application customizations in an isolated environment
• A containers
Are t i that
th t hold
h ld ttemporary copies
i off configurations
fi ti and
d customizations
t i ti
– Created by developers and administrators to make and test customizations
– Take a "snapshot" of the current mainline state
• Help isolate and control customization efforts
– End users work in the mainline, and are not affected by changes within sandboxes
• Typical
yp flow:
Test Prepare
Setup Extend
Private(Test- customizations Get approval for
only) Sandbox Configure and without the changes and
extend publishing prepare to roll
Setup application as
Test out (Integration
per the Sandbox)
requirements
Snapshot: The concept that a sandbox is taken at a fixed point in time is very important. If
Developer A creates a sandbox on 01-Jan-2016, it is a snapshot of the system as of that date. If
Developer B were to then publish a sandbox (write modifications to the mainline) on 05-Jan-2016,
then Developer A's sandbox would immediately be obsolete, and would need to be discarded.
Therefore, managing sandboxes should be a group effort on your team.
• When making
Wh ki any change
h made
d tto th
the application
li ti th thatt impacts
i t Metadata
M t d t S Services
i
(MDS) artifacts, for example:
– Customizing or extending pages, objects, fields, or so forth using Application
Composer
– Setting up security for custom objects, also using Application Composer
– When making any changes using Page Composer
• Oracle
O l Sales
S l Cl
Cloud
d iincludes
l d sandbox
db enforcement
f
– You are not allowed to perform protected actions unless you are in a sandbox
• Before
B f a developer
d l can makek customizations
t i ti within
ithi a sandbox,
db h
he or she
h mustt
"Activate" it
– Ensures that all customizations made by the developer are stored in the sandbox
copy of the metadata
• Each developer may have only one sandbox active at a time
– Any number of sandboxes can exist
– Any number can be active (with different developers)
• A currently-active sandbox is shown at the top of the application screen
An active sandbox
Users must have the CRM Administrator Role to be able to manipulate sandboxes, including
creating them, viewing them, activating them, and deleting them.
• Copying
C i sandbox
db metadata
t d t tto th
the mainline
i li iis referred
f d tto as ""publishing"
bli hi " the
th sandbox:
db
– Overwrites existing customization files with the sandbox versions of the files
– All sandbox customizations are immediately available to all users of the application
– The sandbox is marked as read-only and only visible in the list of published
sandboxes
Caveat: The moment you publish a sandbox, all other users' sandboxes become out-of-date, and
cannot be published.
"Mainline" is the main code for the application which represents what all users see. A sandbox is a
separated area (a snapshot of the mainline at a point in time) which one developer/user sees.
Any other developers are currently working in the sandbox are returned to the mainline; however,
having multiple developers in a single sandbox violates recommended practices.
• Deleting
D l ti a sandbox
db deletes
d l t allll metadata
t d t associated
i t d with
ith th
the sandbox
db
– It is a "clean" way to discard your sandbox
– It is only possible to delete unpublished sandboxes
• Recommended practices:
– Confirm that a sandbox is not active before deleting it
— You may accidentally discard desired changes
– Delete all "stale" sandboxes
— Once one sandbox is published, all other sandboxes should be deleted and new ones
should be created
— Avoids stale data
Metadata Vs. Data: While sandboxes isolate metadata such as object definitions, any 'real' data
created in a sandbox, such as object records, lookups, and so forth, are stored in the database, and
will continue to exist even if the sandbox is deleted.
• Every developer
E d l should
h ld create
t hi
his or h
her own sandbox
db
– No one should modify the mainline directly
– Each developer makes and tests his or her own customizations in his or her own
sandbox
– No sandboxes are published to the mainline (yet)
• Create an "Integration Sandbox" before starting development
– This is not a special sandbox type, but rather a sandbox your team designates as the
"master"
– It is created specifically to contain all approved modifications
– This sandbox is the "master repository" of approved changes
– It is the only sandbox that is published
Activities that do not occur in sandboxes: There are certain activities, such as editing business
processes or creating e-mail templates, that require a developer to be in the mainline. Such activities
will generate a warning if you are in a sandbox. Therefore, best practice is to always work within a
sandbox unless the application specifically notifies you that you should exit your sandbox.
IMPORTANT: There is no flag, checkbox, or other indication distinguishing an "integration sandbox"
from any other sandbox in the application
• Your team must designate and recognize an "integration sandbox" and use it appropriately
• The application does not distinguish between your designated integration sandbox and any
other sandbox
• With an integration
i t ti sandbox:
db
– Each developer uses a dedicated sandbox to make his or her own customizations
– Once those customizations are completed, tested, and approved, each developer re-
keys his or her customizations into the integration sandbox
– The integration sandbox is the only sandbox published
– All other sandboxes are then deleted
• The FND_SB_PUBLISH_BUTTON_PRIV
Th FND SB PUBLISH BUTTON PRIV security
it privilege
i il allows
ll users tto publish
bli h
sandboxes
• To ensure that only the integration sandbox is published:
– Remove this privilege from all non-administrator roles
– Add the privilege to a specific role and grant that role to the integration sandbox
administrator/publisher
D 1
Day1:
1. Private Sandbox A created by Administrator 1
2. Private Sandbox B created by Administrator 2
1 1 1
3. Private Sandbox C created by Administrator 3
X X X
4. Integration Sandbox A is created 2 2 2
5
Day2: 3 3 3
1. Each of the administrators have extended the 4 4 4
application to meet their requirements
1
2. Tested configurations and are ready to be rolled out
Day3:
Day5:
1. Changes approved
1. Integration Sandbox A is published
Day4: 2 On publish of Integration sandbox
2. sandbox, all the private
1. Re-key approved changes to Integration Sandbox sandboxes become stale
• Sandboxes
S db should
h ld exist
i t ffor a short
h t period
i d off ti
time
– Minimizes the risk of stale data in sandboxes
• Sandboxes can be discarded if the customizations are unsatisfactory
– There is no need to try to “work around” a bad customization
• Sandboxes exist until they are explicitly deleted or published
– Once one sandbox is published, other existing sandboxes become stale and should
be deleted
• While sandboxes prevent users outside of the sandbox from seeing in-progress
customizations, they do not prevent two developers in two different sandboxes from
working on the same object
Continued...
• Sandboxes
S db only
l iisolate
l t changes
h made
d tto metadata
t d t using
i A Application
li ti C Composer andd
Page Composer
– For example, creating a new opportunity while in a sandbox creates that opportunity
in the mainline, since opportunities are not metadata
• When activating or deactivating a sandbox, best practice is to sign out and sign in again
– Technically, this is only necessary for sandboxes containing business components
customizations to avoid any inconsistencies between the run time caches and the
ADF Business Components definitions
– Being in the habit of doing so avoids issues
• Best practice is also to be in sandbox even when one navigates to Application
Composer just for browsing
Continued...
• Lookup
L k ttypes and d values
l are seed
dddata,
t nott metadata
t d t
– Therefore, lookups created or modified while in a sandbox are created or modified in
the mainline
• Custom fields created in a sandbox are not generally available until the sandbox is
published:
– Web services
– Custom reports
– File-based import and export
In earlier releases of Oracle Sales Cloud, it was not possible to configure custom subject areas from
within sandboxes. Starting in Release 10, setting the profile option
ZCX_ENABLE_CSA_SANDBOX_Y_N=Yes enabled this functionality.
• If one d
developer
l publishes
bli h a sandboxdb and d a second
dddeveloper
l ttries
i tto publish
bli h a sandbox
db
that modifies one of the already-modified objects, that developer receives a warning that
the object has been updated outside of the sandbox
– The developer can choose to ignore the warning and publish anyway, overwriting the
original developer's modifications
T create
To t and
d test
t t customizations
t i ti within
ithi a sandbox:
db
1. Create a sandbox
2. Activate the sandbox
3. Make your customizations
4. Review and test the customizations
5. If necessary, submit the sandbox for review and approval
6. Publish the sandbox
• A ''sandbox'
db ' is
i a snapshot
h t off the
th MDS att the
th time
ti it is
i created,
t d allowing
ll i d developers
l tto ttestt
customization changes before deploying them
• Publishing multiple sandboxes may cause conflicts, so developers should:
– Create and test customizations within their own sandboxes
– Once tested and approved, re-key their customizations into an 'integration sandbox'
– The integration sandbox should then be published
• Once a sandbox has been published, the changes are
applied to the mainline, and users immediately see the
modifications