Subject areas are groups of data sources that are related to each other in a certain context and on which we can run analysis using the Oracle BI tools.
In Oracle Sales Cloud, a standard set of these subject areas are available for creating reports. These allow us to report on accounts, opportunities, leads, activities and all the different data sources that are available in Oracle Sales Cloud. With each new version, more are being added e.g. in the latest release, we can now report on opportunity assessments.
But what happens when we extend Sales Cloud using App Composer?
- Adding new fields to an existing objects can be added. These are automatically made available for reporting as they get added to the standard subject areas.
- If we create new custom objects then we need to create custom subject areas.
There are 2 scenarios where I see custom subject areas very useful:
- To add reporting capabilities on custom objects, a custom subject area needs to be created that puts the custom object in the context of the relationships it has with other objects.
- To simplify the standard subject areas, a custom subject area could provide a simplified version of the standard subject areas with a limited number of fields. I created such a custom subject area in the example described below. These are ideal to hand over to end users who can use these combined with the BI Composer to make simple reports.
This is of course a configuration task and as such only of interest to those users maintaining the system. End users will only see the end result. A new subject area that allows them to create reports on data captured in a custom object.
In order to make a custom subject area, the App Composer provides an 8 step process:
Let me go through the different steps to explain what they allow you to do.
This might get a bit technical though, so get a cup of coffee first.
Define Custom Subject Area
Specifying a name and description is the first thing to do when creating a custom subject area. This general definition will be visible to the end user when he is prompted to pick a subject area when he starts the creation of a new report.
More important is the choice of the primary object. The primary object is the object arround which you want to define reporting capabilities.
Select Child Objects
Once a primary object is chosen, relationships to other objects that might provide context or details about the chosen objects can be added. These do not necessarily need to be actually child objects according to the object relationship definitions. But they will act as child object in the subject area.
The child objects can be picked from any object that has a normal relationship defined with the parent object. These can be identified in the object relationship manager in App Composer as relationships of type ‘Standard’, ‘Parent-Child’, and ‘Many-to-Many’. The relationships of type ‘Choice List’ are covered later.
In my example, I could have chosen any related object to the opportunity object, and their related objects. I could have created a hierarchy of objects on which the subject area will provide reporting capabilities. But I wanted to keep it simple:
- I started off with ‘Opportunity’ as my primary object.
- The ‘Account’ object is a parent object to ‘Opportunity’ as each opportunity needs to have an account. But as the image below shows, I chose the Account object and it will act as a child object in the subject area as this subject area is centered on the ‘Opportunity’ object.
- I added the ‘Opportunity Revenue Lines’ object as child object as I want to be able to see which products have been picked on opportunities.
Once the objects are chosen, the fields for each of the chosen objects need to be picked. Out of the long list of possible fields that both of the objects have, I chose only to pick a handful. I have set the default measure aggregation for the ‘Revenue Line Revenue’ to SUM.
When picking these fields, there is also an option to pick related object fields. These are the related objects identified in the object relationship manager as relationships of type ‘Choice List’ I mentioned earlier when going over the option on including child objects. These indicate implicit relationships created by adding a picklist (e.g. an account picklist field) as a custom field on an object.
Configure Implicit Facts
One implicit fact must always be selected when creating a subject area, they play a pivotal role when a user is making a report, for whatever reason, does not use a fact in his report.
Facts are what link the objects logically together in a subject area as shown in the picture below. In case where an end-user creates a report without choosing a fact, a hidden fact needs to be used to make the link. This is where the implicit fact comes into play.
Configure Marketing Segmentation
The marketing segmentation step no longer serves a purpose and can be skipped. Its functionality has been taken over by the Oracle Marketing Cloud.
Configure Date Leveling
By allowing leveling on a date field like the ‘Close Date’ field, the subject area generation immediately will add aggregated fields so that I can immediately can group opportunities per close date month, or close date quarter, …
The previous steps were all about the content of the custom subject area. This step is all about who is allowed to use the subject area for reporting. You can make the subject area available to everyone as I did in this example, or grant access by role.
This is about who is allowed to make reports based on this subject area. This has nothing to do with the actual data that the subject area will be providing. Data visibility is regulated by Sales Cloud itself.
Review and Submit
Once the custom subject area has been defined, all that is left to do is to submit. Once the subject area is published, it is ready for usage by each of the BI Tools that come with Oracle Sales Cloud.
Unlocking the information in custom objects in Sales Cloud for reporting purposes through a custom subject area is a fantastic capability of Sales Cloud. Why would you want to capture information in any application if you cannot report on it right?
All of this might have been a bit technical, but end users using Sales Cloud will never encounter such configuration tasks. But as I mentioned earlier, end users will only see the end result.