7Custom Subject Areas

This chapter contains the following:

With your applications, you get prebuilt analytics that answer typical business questions you might have. But in case your questions aren't answered, you can create your own analytics using prebuilt subject areas. And, if the prebuilt subject areas don't cover what you need, then you can create your own custom subject areas to use to create analytics that do answer your questions. This feature is especially useful as you work through the process of configuring your applications. For example, if you create custom objects and want to report on them, then you will need to create custom subject areas.

Subject Areas and Analytics

What's the relationship between subject areas and analytics?

A subject area is the starting point for building analytics. It's basically a collection of related information from your database. Analytics, meanwhile, are like snapshots of a subject area. They give you a focused view of that collection of information, so you can get more meaningful insights from your data.

You can look at a subject area like a painter's palette and the resulting analytics are the completed paintings that you create. The subject area contains all the colors you need to paint one or more pieces of artwork. And your finished artwork gives you the intelligence you need to better understand and operate your business.

When to Create Custom Subject Areas

Creating custom subject areas isn't required, and you do get prebuilt subject areas that contain a lot of information from which you can build your own custom analytics. You will need to create custom subject areas, however, for two reasons:

  • If you create custom objects and want to report on them

  • If the existing prebuilt subject areas don't contain the measures (facts) you need for reporting

How to Create and Use Custom Subject Areas

To create a custom subject area, you're guided through the process step by step, but here's a quick overview:

  1. Navigate to Application Composer.

  2. Click Custom Subject Areas on the Overview page of Application Composer.

  3. Select Create from the Actions menu.

  4. Complete the guided process.

Next, to actually build analytics from that subject area, use BI Composer. Using a custom subject area in BI Composer is the same as using a prebuilt subject area.

  1. From the Navigator menu, select Tools > Reports and Analytics.

  2. In the Contents pane, click Create.

  3. Select the published custom subject area and start creating your analytic, such as a report or an online analysis.

Things to Remember

Before you start creating custom subject areas, you should know the following:

  • Tools:

    • Use Application Composer to create custom subject areas. Then use BI Composer to create analytics based on those custom subject areas.

    • If you're using Configuration Set Migration to migrate your configurations, then create custom subject areas in the source environment, not the target environment. Otherwise your custom subject areas will be overwritten when you do the migration. And, after a migration, remember to always resubmit your custom subject areas for publication in the target environment so that they're visible in BI Composer.

  • Objects: A subject area is always built around a business object. That object is the focus of any reporting created using that subject area. You can add related objects to a subject area, but there is always a primary object and you can't change it.

  • Dates and numbers:

    • The real meaningful substance of any reporting is typically "how much" or "how many." You're measuring things to get insights into how well your business is doing. When creating a custom subject area, you can tag attributes of the custom subject area object as measures, which means you specify which date and number fields are measurable. You will use these measures when you later use this subject area to create analytics.

    • You can also enable date leveling, which means that you can group the data in your analytics by different calendar attributes. You do this by mapping a date attribute to a calendar object, like Week Of the Year, Month of the Year, or Enterprise Quarter. This mapping lets you view data in your analytics by a specific quarter or year, for example.

  • Publishing: Once you create a custom subject area, you can't actually use it in BI Composer until you publish it.

In the next few topics, we will review some of these key concepts. We will then talk in more detail about how to create custom subject areas.

When you create a custom subject area, one of the first things you do is pick the primary object. The primary object is the focus of any reporting created using that subject area. Does your subject area need more data to be helpful? If so, then just add child objects to the subject area. A subject area always has one primary object and, depending on your reporting needs, could have one or more child objects. Still need more data? You can further expand the scope of information by adding related objects as well. Let's look at these objects in more detail.

Primary Object

You pick a primary object during the first train stop when creating a custom subject area. The list of available objects includes all standard objects as well as top-level custom objects. A top-level object is simply an object without a parent.

After you save your custom subject area, the primary object is frozen and can't be changed.

Note: You can't include Notes and Tasks in a custom subject area.

Child Objects

To expand the scope of information that you can report on, you can add one or more child objects during the second train stop when creating a custom subject area. After adding child objects, you can include data from both the primary object and its children in the analytics you create from this subject area.

In a family, one parent can have many children; we call this a one-to-many relationship. In Application Composer, you create this type of relationship by creating a parent object with one or more children. So, if a parent object is the primary object of a custom subject area, then you can add its children to the subject area, too. Note that in Application Composer, you can't create a child object of a child object (grandchildren).

When you create custom subject areas, however, it's a little different. Yes, you can add child objects to a subject area. But, you add child objects in sequential order. It's a single hierarchy of objects: parent-child-grandchild-great-grandchild.

Here's a screenshot of what the parent-child-grandchild-great-grandchild hierarchy looks like.

This screenshot illustrates the parent-child-grandchild-great-grandchild
hierarchy that you can create when adding child objects to a custom
subject area.

The parent-child-grandchild-great-grandchild hierarchy supports adding up to three levels of child objects with one child object at each level; for example, parent-child1-child1.1-child1.1.1. If no child objects exist for the selected primary object, then you can't add child objects to a custom subject area.

After you publish a custom subject area, you can't add or remove child objects.

Related Objects

If you need still more data in your custom subject area, above and beyond what you can get from the primary object and its child objects, then you can also include attributes (fields) from related objects. You do this during the third train stop when creating a custom subject area.

Think of related objects like friends of the primary object. They aren't quite children, but they still have a relationship with the primary object. A related object doesn't have a parent and can exist on its own. In contrast, child objects can't exist without a parent. So, instead of the parent-child one-to-many relationship, related objects have a many-to-one relationship with the primary object. You can think of that like many people can be friends with the same parent. In Application Composer, you create this type of relationship by creating a many-to one relationship on the Relationships page.

After you publish a custom subject area, you can't remove related objects, but you can always add new related objects and republish your subject area.

After you pick the primary object and add child objects to a custom subject area, the next train stop in the process is to pick the fields (also called object attributes or just attributes). If you recall, a subject area is a collection of information from your database, and analytics are snapshots and measurements of that information. Picking the fields is the part of the process where you build that collection of information in your subject area. When you're later using this subject area to design an analytic, you will be able to choose from the set of fields that you included in this step.

Where Fields Come From

The fields that you can pick belong to the primary object and any child objects that you added in the previous train stop. You can also add fields from objects that are related to the primary object.

Tip: Fields represent a column of information contained in an object. When you build your analytics in BI Composer, you build them by adding columns. Columns and fields in relational database terms are the same thing.

Types of Fields You Can Add

There are different types of fields in your applications. You can add most of these types to custom subject areas. Here's what you can add:

  • Text

  • Number

  • Date

    Keep an eye out for date fields that are canonical date candidates, which are predefined for some standard objects and subject areas, and display with a read-only check mark. Optionally add canonical date fields from the lowest standard object in your custom subject area. This means that, if you later join your custom subject area to a standard subject area in BI Composer, you can create analytics that can drill up and down the date hierarchy.

    For example, maybe users want to see sales commission amounts on their closed opportunities for the quarter, and then drill down to view amounts by week. And maybe they also want to drill up to view amounts by year. This drill down is enabled because the canonical date field in your custom subject area is automatically joined to the standard Time dimension in the standard subject area.

  • Percentage

  • Date time

  • Currency

  • Check box

  • Fixed choice list

    In your analytics, only the actual user selections are displayed, as text strings.

    It's a good idea to avoid adding multi-select fixed choice list fields to your custom subject areas, since only the first selected values are displayed in analytics, not all selected values.

  • Dynamic choice list

    In your analytics, only the actual user selections are displayed, as text strings.

  • Long text

Types of Fields That BI Composer Supports

Meanwhile, BI Composer supports a corresponding set of data types when creating analytics. It's basically the same as the types of fields you can add to a custom subject area in Application Composer. But, there are slight differences in terms of how check box fields and choice list fields in a custom subject area are interpreted in BI Composer.

  • Boolean

    Note: Check box fields from your objects are interpreted as Boolean fields on the BI side.

    If you're using the Boolean data type for fields other than check boxes, then those fields are displayed as either 0 or 1 in your analytics.

  • Number

  • Currency

  • Date

  • String

    As mentioned above, fixed choice list and dynamic choice list fields are interpreted as string fields on the BI side.

  • Percentage

  • Date time

  • Long text

When you want to see how your business is doing, you typically review analytics to find out "how much" or "how many." Keeping on top of this kind of summary data helps you to evaluate your company's performance. To get the exact summaries you need, you specify the date and number fields in your custom subject areas that you want to summarize, and you also specify how you want to summarize them. These fields are called measures.

What's a Measure?

Measures are a set of functions applied to a date or number field so that your users can see summaries in their analytics. Examples of typical measures include a SUM of the revenue in Euros, or a COUNT of the number of opportunities worth over $500,000.

When you create a custom subject area, you pick the aggregation function (SUM, COUNT, and so on) for measures. You can apply these functions on fields of type Date, Numeric, or Currency. After you define the measures for the required fields and publish the custom subject area, you can select these fields and the applied measures when creating analytics in BI Composer.

Tip: The measures you define in Application Composer display in the Facts folder in BI Composer.

Things to Remember

You can specify measures only when creating a custom subject area. You can't delete measures in an already published custom subject area, but you can add new measures. You can't edit or add measures to a standard, prebuilt subject area.

If you don't define a measure, then one will be automatically selected from the lowest object in the custom subject area when you submit the subject area for publication.

Measures and Field Types

Select measures based on your reporting needs. For example, you can use measures to view product sales per store, state, or country. Or, use measures to view the number of support tickets opened or closed per day, week, or month, and so on. But keep in mind, the measures available for selection might differ depending on the field type.

Here are some measures you can apply to fields of type Numeric, Currency, or Date.

  • For Numeric and Currency fields, a measure can be:

    • All

      Note: All isn't a measure, but an option in the UI that selects all of the measures.
    • Sum: Calculates the sum of the values.

    • Average: Calculates the mean value.

    • Count: Calculates the number of rows that aren't null.

    • Count Distinct: Calculates the number of rows that aren't null. Each distinct occurrence of a row is counted only once.

      Note: Although Count Distinct is usually used in cases requiring a count on a foreign key (because a count of distinct rows is what's wanted), it's not required. If your requirements allow multiple instances of the same foreign key value to be counted multiple times, you can use Count rather than Count Distinct.
    • Maximum: Calculates the highest numeric value.

    • Minimum: Calculates the lowest numeric value.

    • First: Selects the first occurrence of the item.

    • Last: Selects the last occurrence of the item.

    • Median: Calculates the middle value.

    • Standard Deviation: Calculates the standard deviation to show the level of variation from the average.

    • Standard Deviation Population: Calculates the standard deviation using the formula for population variance and standard deviation.

  • For Date fields, a measure can be:

    • All

    • Maximum

    • Minimum

Once you pick the fields for your custom subject area, you can then review just the date fields for two additional configuration steps: allowing date leveling and picking one canonical date field. First, you can enable one or more fields for date leveling which enables the aggregation of report data over a period of time. You can also enable one field to be the canonical date which lets you join this custom subject area to the standard Time dimension. Using this common date, your users can filter data across multiple subject areas in a single report, and drill up and down the date hierarchy. Let's look at date leveling and the concept of canonical date in more detail.

Why Date Leveling is Useful

Date leveling gives you additional date context about your transaction data, and enables the filtering of data by calendar attributes. Date leveling means that you're connecting (mapping) a date field in your custom subject area to a very large calendar object in BI Composer. Later, in BI Composer, that date field will display with a series of calendar attributes. (The calendar object supports both the enterprise and fiscal calendar.) When you design your analytics, you pick that date field plus the calendar attributes you're interested in, such as Day Name, Week of the Year, Month of the Year, or Enterprise Quarter. In your resulting analytic, transaction data displays along with the helpful date context that you have added.

For example, a report can display a set of opportunity records along with the enterprise quarter they were created in: Q1, Q2, and so on. That's date leveling. And, maybe you need to know which day the opportunity was created on, such as on a Monday or Wednesday. That's also date leveling.

Maybe you want to see a report of all orders entered, but you would like to know what enterprise quarters they were entered in. If you enable date leveling on the creation date for your sales order object, then you can create analytics that show orders per enterprise quarter.

Let's refine that report a little more. Maybe you want to see only orders created in 2019 Q1. When you design that report, add a filter on the enterprise quarter to display only records where the quarter is equal to 2019 Q1.

If you don't enable date leveling for a date field, then later in BI Composer, that date field will still display for inclusion in an analytic, but without the added calendar attributes that are so helpful.

Configure Date Leveling

To configure date leveling, use the Configure Dates step of the guided train process to either allow or disallow leveling for a date field. You might need to expand the field list in the Date Field column to view the Allow Leveling check box.

Enable date leveling only for those dates that you want to report on. And, even after you publish the custom subject area, you can always come back and select additional dates for date leveling, and then republish.

Why the Canonical Date is Useful

A canonical date in a custom subject area is useful because, when you join your custom subject area to a standard subject area in BI Composer, the canonical date automatically joins to the standard Time dimension. The Time dimension includes the date hierarchy, so this means that the analytics you create can drill up and down the date hierarchy.

But first, let's understand where the canonical date comes from. Canonical dates are already defined for some standard objects. You can see these fields in the Fields step when adding fields from standard objects to your custom subject area. (A date field that's a canonical date will have a check mark in the Canonical Date Candidate column.) If you plan to design a report that lets users drill up and down the date hierarchy, then include a canonical date field in your custom subject area. But that's only the first step.

In the next Configure Dates step, you must select the radio button for that field in the Canonical Date column. Do this for one field only, and only for the lowest standard object in your custom subject area. Canonical dates are available only for standard objects because custom objects don't have corresponding subject areas in BI Composer with the standard Time dimension to join to.

Let's look at an example of drilling up and down the date hierarchy. Maybe users want to see sales commission amounts on their closed opportunities for the quarter, and then drill down to view amounts by week. Maybe they want to drill up to view amounts by year. This is drilling up and down. To achieve this, you must do the following:

  1. In Application Composer, create a custom subject area for opportunity and opportunity revenue, with the Line Close Date as the canonical date from the opportunity revenue object.

  2. In BI Composer:

    1. Create an analysis that includes both the custom subject area and a standard subject area, such as Sales - CRM Pipeline.

    2. In addition to including at least the Sales Commission field, include the date hierarchy in your analysis, such as Enterprise Time, from the Sales - CRM Pipeline's Time dimension folder.

Configure the Canonical Date

To indicate which date field should be the canonical date, use the Configure Dates step of the guided train process. To enable a date field as the one canonical date for a custom subject area, view the date fields for the lowest standard object in the custom subject area, and select the radio button for the desired date field in the Canonical Date column. You might need to expand the field list in the Date Field column to view the Canonical Date radio button.

You can add a canonical date to both new and existing custom subject areas.

If you publish a custom subject area without a canonical date, then you can always come back later and select a canonical date, and then republish.

You can secure a custom subject area by granting or revoking access rights from the role names that access the custom subject area. You can add or delete role names, or grant or revoke access rights from those role names.

You can also add role names from a predefined list and assign or revoke permissions.

Manage Role Names and Access Rights

While defining a custom subject area using the train stops, you can use the Actions list in the Configure Security step to manage role names and access rights as follows:

  • Select and add role names for a custom subject area from a predefined list of role names. This predefined list also provides the description for each role name. You can also select and add multiple role names from this predefined list using either the Shift or Ctrl keys. After you add a new role name, you can select appropriate access for that role name.

  • Select and delete role names listed for a custom subject area. You can also select and delete multiple role names using either the Shift or Ctrl keys.

    Note: You can't delete the role name listed as Everyone.
  • Read access is granted by default to each role name you add. To revoke Read access from a listed role name, select No access for that role name.

Note: You can create custom subject areas even for the objects whose data you don't have access to. This way you build custom subject areas without compromising data security.

Creating a subject area is simple. In Application Composer, just follow the train steps.

Tip: Before you create a custom subject area, review all the prebuilt subject areas to see if the one you want is already available.

Creating a Custom Subject Area

To create a custom subject area, you can't be in a sandbox.

  1. Navigate to Application Composer.

  2. Click Custom Subject Areas on the Overview page of Application Composer.

  3. Select Create from the Actions menu.

Here are the steps in the train stops that you can use for configuring your custom subject area:

  1. Define Custom Subject Area

    In this step, you provide the name for your subject area and select the primary object that is the basis for the reports you create later using the custom subject area. Subject areas usually have names or labels that correspond to the type of information they contain, such as service requests and orders. Display labels have the Custom: prefix added automatically.

  2. Select Child Objects

    In this step, you select the child objects whose data you want to use in your reports. You can add child objects only if the primary object has child objects. Otherwise, the add icon is disabled. You can only add one child object per level. The parent-child-grandchild-grand grandchild hierarchy supports adding up to three levels of child objects with one child object at each level, for example, parent-child1-child1.1-child1.1.1.

  3. Configure Fields

    In this step, you select the fields that you want to display on your reports. You typically add at least one field from each of the objects that you have selected for your custom subject area.

    Select the desired measures to generate for number, date, or currency fields from all the available objects so that the subject area includes only those measures that you want to analyze. Also, define at least one measure.

    In the Measure Aggregations column, select an option from the list of predefined formulas that you can apply to the Measure field. When you select the formula, the application applies the selected formulas to the selected field as measures.

    Note: You can choose measures only for the lowest child. For example, if only a primary object exists with no children, you can select measures for the primary object. Otherwise, if any child objects exist, you can select measures only at the lowest child object level, not for the parent object.

    In the Canonical Date Candidate column, notice which standard object date fields are already defined as canonical dates. Canonical dates are already defined for some standard objects that support the Time dimension in standard subject areas, and display with a read-only check mark. Optionally add this field from the lowest object in your custom subject area. This means that you can later join your custom subject area to a standard subject area in BI Composer, and create analytics that can drill up and down the date hierarchy.

    You can change the display labels of the fields that you select in this step. Additionally, you can use the Select Fields dialog to remove fields that belong to the primary object, or add fields from the related objects. The Select Fields dialog appears when you click Select Fields when configuring fields for your custom subject area.

    After you publish your custom subject area, the fields you have selected for your subject area are automatically added to their owning object's folder. If you have also defined measures, those fields are automatically added to the Facts folder. If you didn't define a measure, then one is automatically created for the custom subject area.

  4. Configure Dates

    If required, select one or more Date columns for date leveling. Date leveling lets you add calendar attributes to your analytics, which provide better context to your transaction data.

    You can also optionally select one date field to be the canonical date for the custom subject area. Do this if you want to create analytics that can drill up and down the date hierarchy.

    For more information on configuring date fields in a custom subject area, see Custom Subject Area Dates.

  5. Configure Security

    Select the required security level for the Everyone Role Name, which is added by default, or add additional Role Names by clicking in the + icon and define the security level for each one of them.

    The security definition here only controls who can access the custom subject area definition to create reports. It doesn't control data visibility which is automatically controlled based on the user running the reports.

    For more information on securing custom subject areas, see Secure Custom Subject Areas.

  6. Review and Submit

    Review the custom subject area configuration for all added objects, attributes, and measures, and if satisfied, click Submit. If changes are required click Back to navigate back to the required screen.

    This figure shows the custom subject area configuration.

    Review custom subject area

    After you submit, the custom subject area configuration is prepared for publishing. You can create and submit a custom subject area either immediately or save and close the custom subject area at any point and submit it later. You must first submit a custom subject area for publishing before you can select it from within Oracle BI Composer. After you save or submit a custom subject area, you can't modify its primary object.

    To access the published custom subject area in BI:

    • From the Navigator menu, select Tools > Reports and Analytics.

    • In the Contents pane, click Create.

    • Select the published custom subject area and start creating your report.

Editing Custom Subject Areas

You can edit a published or saved custom subject area and then republish it when your changes are done. Modifying a custom subject area doesn't affect the reports that you had created using that custom subject area before making the changes. You can use the modified custom subject area if you need to enhance existing reports.

To edit a custom subject area:

  1. On the Overview page of the Application Composer, click Custom Subject Areas.

  2. Locate the custom subject area that you want to edit, and click the Edit icon.

    You can filter out inactive custom subject areas in Application Composer by viewing custom subject areas in Active status. This is safer than deleting them, because the inactive subject areas are still available and can be found by searching.

  3. Make the desired changes and then click Submit to republish the custom subject area.

While you can edit a custom subject area in any status, there are considerations on what you can or can't do when editing. When editing a published custom subject area, it's not possible to:

  • Change the primary object.

  • Add or remove child objects.

  • Remove related objects.

  • Remove fields.

  • Remove previously added measures, date levels, and canonical dates.

  • Add more aggregation types for measures that are already published.

Note: You can't modify a predefined, standard subject area. Instead, you must create separate custom subject areas to meet your reporting needs. Before you create a custom subject area, be sure to review all the included subject areas to see if the one you want is already available.

Activating or Inactivating Custom Subject Areas

When editing custom subject areas, you can activate or inactivate custom subject areas when your reporting or business requirements change. This step enables you to control what information is displayed on the reports that use the information from custom subject areas.

You can inactivate only those custom subject areas that are published and have a status of OK, and can activate only previously inactivated custom subject areas.

To inactivate a custom subject area, select it in the list and then click the Inactivate button. To activate an inactive custom subject area, select it and click Activate. Note that if no custom subject area is selected in the list, the button doesn't appear.

This graphic shows an active custom subject area selected, and the Inactivate button.

Custom subject area selected showing Inactivate
button

When searching for custom subject areas, you can filter out inactive custom subject areas in Application Composer by viewing only those in Active status. Inactivating a custom subject area is safer than deleting it, because the inactive subject areas are still available and can be found by searching.

After you create a custom subject area, you must publish it so that it's available for use in BI Composer. A custom subject area can have a few different publication statuses. Let's look at each one.

What Happens When You Submit for Publishing

But first, let's understand the publication process. When you submit a custom subject area for publishing, two processes occur in the background. The first process is synchronous and creates Oracle Applications Development Framework (Oracle ADF) artifacts. You must wait until this first process is over. The second process is asynchronous and creates centralized metadata repository (RPD) fragments and submits them to the Oracle BI server.

If you're working on multiple custom subject areas at once, then be sure to publish them one at a time. The first custom subject area might publish successfully, but subsequent custom subject areas could result in publish failures.

Publication Statuses

A custom subject area can have one of the following statuses:

  • Pending: This status indicates either of the following:

    • You saved and closed the configuration process for a custom subject area before submitting it for publishing.

    • A failure occurred in the background processes when creating Oracle ADF and RPD artifacts.

  • In Process: This status indicates that the data is in the process of being published to Oracle BI.

    Note: If the in-process status doesn't change to OK, even after multiple refresh attempts, then there could be an error in publishing. If an error occurs, then the details are displayed as well as information about how to fix problems, where applicable. Use these error status details to pinpoint and fix problems quickly.
  • OK: This status indicates that the custom subject area has been published successfully. You can use BI Composer to create reports using the objects, attributes, and measures that you have configured in the subject area.

Note: You must refresh the status to know whether the custom subject area was submitted successfully. You might have to refresh the status multiple times because it could take a while to create the Oracle ADF and RPD artifacts.

How to Report on Custom Fields

If you add custom fields to certain key standard objects, then you don't have to create a custom subject area just to report on those new fields. Actually, key objects come with predefined extension dimensions. Extension dimensions exist in certain standard subject areas in BI Composer and conveniently hold all your custom fields. This means that if you create a custom field for Opportunity, for example, then you don't have to do anything to report on it. Simply go to your favorite standard subject area for Opportunity; your custom field automatically appears in the extension dimension, ready for inclusion in analytics.

Create Analytics Using Extension Fields

Here's how to create analytics using extension dimension fields:

  1. In Application Composer, create custom fields for standard objects, and add those custom fields to the user interface.

  2. Publish the sandbox.

  3. From the navigator, select Reports and Analytics under Tools to navigate to BI Composer.

  4. Select a standard subject area whose primary object is the object that you created custom fields for.

  5. Create your analytic.

    When you specify the columns to include, you can select the extension fields from the extension dimension folder, which appears as the <Object Name> Extension folder. For example, Opportunity Extension.

    The extension fields available for reporting vary by object type.

Hierarchies in Analytics

Some prebuilt, standard subject areas include hierarchies, such as a customer or territory hierarchy. When you design analytics with a hierarchy, users can drill up and down that hierarchy to view data grouped at different levels. For example, with a territory hierarchy, users can drill up and down their data to look at information grouped by region, state, and city. Hierarchies are delivered with standard subject areas only; you can't add them to custom subject areas. What you can do, however, is join your custom subject area with a standard subject area that has the hierarchy you need. This lets you create analytics with a hierarchy using data pulled from your custom subject area.

Supported Hierarchies

The following hierarchies are supported in some standard subject areas, such as Sales - CRM Pipeline:

  • Resource

  • Territory

  • Customer

  • Partner

Example of Adding a Hierarchy to Analytics

If you want to create analytics that include a hierarchy, and also pull data from a custom subject area, then here's how you do it.

Let's say you have a custom object named Ticket that you want to report on. The Ticket object includes the Account field as a dynamic choice list. This means at runtime, your users can create tickets and assign accounts (customers) to them.

Now you have 1,000 tickets in your database and it's time to report on them. Your users would like to view total number of tickets up and down their customer hierarchy.

Here's how you can create a report to meet this need:

  1. Create a custom subject area for Ticket and publish it.

  2. Create a report using a standard subject area, such as Sales - CRM Customer or Contacts Real Time. These subject areas include the customer hierarchy.

  3. Add the account hierarchy from the subject area to your report.

  4. Next, add your Ticket custom subject area to the report. This "joins" the two subject areas.

  5. Finally, add the metric, such as Number of Tickets, from the custom subject area to your report.

Custom Subject Areas: Frequently Asked Questions

How can I report on custom objects??

To report on custom objects, you must create and publish a custom subject area in Application Composer. Once you have done that, then creating analytics in BI using a custom subject area is the same as using a standard subject area.

No. Once you save a custom subject area, you can't change its primary object. You can, however, create a new custom subject area with a different primary object.

You can edit a published custom subject area and then republish it after your changes are done. Modifying a custom subject area doesn't affect the reports that you created using that custom subject area before making the changes. You can use the modified custom subject area should you need to enhance existing reports.

Note: You can't edit a primary object when you modify a custom subject area. Should you need to do so, create a new custom subject area using a different (new) primary object.

You can use Configuration Set Migration to migrate your configurations, including custom subject areas, from a source to a target environment. After a migration, however, you must always resubmit your custom subject areas for publication so that they're visible in BI Composer.