Workday Composite Reporting Hack Using Object Transporter

Hello Fellow Workday Aficionados –

This post is intended to provide a solution to make life easier when it comes to creating copies of composite reports or making changes/updates to existing composite reports and their related sub reports.

Have you ever needed to create a second iteration of a composite report, but only for the purposes of a slightly different layout or presentation? Have you ever needed to update a sub report(s) used in a composite report but realized the sub report(s) is used in several other composite reports? Chances are, the configuration changes you make to the sub report (perhaps to bring in an additional column grouping/row grouping/prompt, etc.) will have unintended impacts in other areas of Workday where the sub report is used. For this reason, and many other reasons (we will share in a later blog 😊) it’s always best to maintain a 1 to 1 relationship between sub reports to composite reports.

As such, you likely will consider one of the following options:

1. Copy the composite report and realize the newly copied version of the composite uses the same version of the sub report(s) as the original composite report, creating a 1 sub report to many composite reports’ relationship.
2. Copy the composite report and create a new sub report(s) version for your new composite report. When you attach the new sub report(s) to your copied composite report, you will go through the painful process of updating prompt mappings on columns, rows, cells, etc. just to make a few minor changes! Of course, during the process, you are navigating through the many different red error messages at the top of your report, wondering if you are effectively updating what you need to. What a nightmare!
3. Create a new composite report and new sub report(s) from scratch and completely rebuild. This is the most time intensive process, and not the most efficient in many scenarios.

Rather than electing for one of the above options, I’d like to share a quick tip that will likely save you substantial time and frustrations, regardless of your scenario.

Composite Reporting Trick using Object Transporter (OX), steps below:

Note: The first time you attempt to replicate the above steps, I’d highly recommend using your source tenant and target tenant as both non-production instances. For example, make your changes in an Implementation (IMPL) environment (source tenant) and use object transporter OX to migrate them to your Sandbox environment (target tenant) per the walk-through below.

1. In Sandbox (or source tenant), take a related action on the composite reporting definition you’d like to make changes to via Custom Report > Print. Tip: If you’re not familiar with the power of the ‘Print’ feature, please be sure to review our previous post: “The Workday Composite Report “One-Stop Shop”.
2. On the ‘Sub Reports’ tab, in the ‘Sub Reports’ section, you will find each sub report definition used with the composite report. Open each sub report in a new tab. Tip: In the top right section of the sub report definition, you can view ‘Report Definition Usages’ to obtain details on where the sub report is currently being used. For performance and maintenance purposes, each sub report should only be used in one composite report as mentioned above.
3. Rename each sub report and be sure you are the report owner. Tip: You may want to name the report something just slightly different, perhaps ending with a v.2 or v.currentdate
4. Rename the composite report in a similar manner and be sure you are the report owner.
5. Once all reports have been renamed and report ownership is verified, take a related action on composite report and select Instance>Migrate. On next screen click ‘Launch Object Transporter’. If you do not have this option, work with your security administrator to gain the necessary access.
6. Select the destination (target tenant) for where the renamed composite report and related sub report(s) will be migrated to. Then click ‘Start’ in lower left portion of screen.  This will prompt you for credentials to the target tenant and begin the migration process.
7. Once the migration process has completed, review the target tenant to ensure the original composite report, which you renamed in the source tenant, still exists in its original form. Also check to ensure each original sub report still exists on the original composite, via the print option discussed above. Further, find the new composite report (renamed in source tenant) in the target tenant, and via the Print Option discussed earlier, verify all new sub reports (renamed in source tenant) also exist and are only used in the new composite report by reviewing the sub report ‘Report Definition Usages’.
8. At this point you have a new version of both the composite report and sub report(s) which you can begin making your configuration updates/changes to.

Of course, you can also utilize OX to copy reports that only exist in a source tenant to a target tenant as the need arises.

Thanks for taking the time to read and happy Composite Reporting!