Custom Subject Areas

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 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 service requests.

But what happens when we extend Sales Cloud using App Composer?

• We can add new fields to an existing objects (except dynamic choice lists) but these get automatically added to the standard subject areas.
• We can build out complete new custom objects or add dynamic choice lists to a standard object.  This will require the creation of custom subject areas

But there is more, there are in my opinion actually 3 scenarios where I see custom subject areas very useful:

• To add reporting capabilities on custom objects: custom subject areas need to be created that put custom object in the context of the relationships they have  with other objects.
• To allow new custom dynamic choice lists added on standard objects being available for reporting purposes
• To simplify the standard subject areas, custom subject areas 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.

Defining Custom Subject Areas

In order to make a custom subject area, the App Composer provides an 6 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.

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 around which you want to define reporting capabilities.

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.  Parent objects are added to a subject area in a different way as will be shown in the next step

In my example, I could have chosen related object to the opportunity object.  I could have created a hierarchy of objects on which the subject area will provide reporting capabilities.  But I wanted to keep it simple:

1. I started off with ‘Opportunity’ as my primary object.
2. I added the ‘Opportunity Revenue’ object as child object as I want to be able to see which products have been selected on opportunities.

Once the objects have been chosen, the fields for each of the chosen objects need to be selected.  Out of the long list of possible fields that both of the objects have, I chose only to pick a handful.  I have also selected the measure aggregation methods for each of the number and currency fields as I saw fit.

For custom fields, custom (related) objects or custom dynamic choice lists, please rename the fields to more meaningful names.  This will make the use of the custom subject areas for end users much easier.

When picking these fields, there is also an option to pick related object fields.  These are the related objects identified as parents in the object relationship manager as I hinter towards earlier.  In this example I will use this technique to include the parent account object and the parent sales method/sales stage definitions.

By allowing leveling on a date field like the ‘Close Date’ or the ‘Creation Date’ field, the custom subject area generation process 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.

Once the custom subject area has been defined, all that is left to do is to submit.  Once the subject area is published (this make take a while but a lot is happening in the background to make this work … so time for a second cup of coffee), it is ready for usage by each of the BI Tools that come with Oracle Sales Cloud.

 Conclusion

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.