InEight Explore

The following workflow shows the relationship between InEight applications, the Connected Analytics database, and the Report and Explore applications (including reports, dashboards, and APIs).

No, using the Reporting APIs in place of the Integration APIs is not supported, nor is it recommended.

Integration APIs source data directly from their respective product’s database, allowing data to appear in the Integration APIs in real-time without a data lag.

Alternatively, the Reporting APIs read data from a consolidated database that aggregates data from the different products’ databases rather than drawing directly from the source database. This increases the likelihood that there could be a point of failure between the product source database and reporting, causing the reporting data to be out of sync.

Also, in the acquisition of this data, there may be a refresh interval that occurs in the background to pull data from the product source database to the reporting database. This opens you up to the possibility that the data may not match what the product user interface reads. This potential data latency can also make scheduling data pulls complicated, especially when you are looking to support critical processes, such as payroll runs.

SelfService APIs are designed to satisfy extraction requirements. These APIs more closely match the source data, though we do some denormalization to combine IDs and text into the same table and ensure field/table naming more closely matches the user interface. Records that have been deleted or updated in the products’ user interface are soft-deleted in the database. These APIs will expose both “active” and “inactive” (soft-deleted) records. An example of this use case would be writing ETL against the data to extract it into a data warehouse that is used to combine data for reporting. However, it is important to note that these APIs can also be used for BI use cases, such as connecting to Power BI.

The APIs prefixed with Explore are designed to satisfy more of a BI use case. These APIs report only active and latest records as reflected in the system. And in some cases, they may have more business logic implemented in the code behind them. They also will have naming conventions similar to what is in the user interface of the InEight applications. An example of this use case would be connecting in Power BI.

For the most part, Explore APIs will have a SelfService counterpart, and the documentation for the SelfService API should apply to the Explore APIs, with some minor differences.

Yes, this is possible. If you need your Client ID and Secret for your selected ETL tool, you can reach out to InEight Support or your InEight representative.

Please note that troubleshooting errors and setting up connections for your ETL tools outside of InEight is not included in our services.

Currently, the refresh time of reporting data varies by product. Most products' data refresh utilizes an incremental load methodology. This means, on an interval basis, our database looks for changes in the product databases based on the modified date on the records. Based on the detected changes, the reporting database updates accordingly.

Some InEight Applications have implemented the architecture for entity change on some or all of their database entities.

An example to entity change is the setting “When the user updates Current Estimate Total Cost of a Cost Item, this change will be reflected within the next five minutes in the corresponding SelfService_Control_CurrentEstimate reporting api”, whereas there are APIs that only refresh once a day. The InEight Plan APIs (listed below) fall into the once a day category.

That means for those entities we can leverage a trigger-based refresh. This means the fresh data will be reflected in the reports and APIs in near-real-time (five minutes or less).

The rule of thumb, however, is twenty minutes or less for all reports and APIs, unless otherwise noted in the API or report documentation.

There are 5 APIs that are on a daily refresh cadence (this applies to these APIs only and does not have any bearing on reports in Report):

• SelfService_Plan_Timecard

• SelfService_Plan_WeeklyTimesheetVersion

• SelfService_Plan_DailyPlanHoursResourceVersion

• SelfService_Plan_DailyPlanHoursResourceDetailVersion

• SelfService_Plan_DailyPlanHoursPayrollIndicatorVersion

The refresh cadence of APIs is published in our API documents.

Pagination is a method of segmenting the data returned by an API in an attempt to not overwhelm it with larger datasets.

All of the reporting APIs have a pagination setting, and most are set to 50,000. However, some of the larger APIs are set to 5,000. This is also noted in the API documentation.

We currently impose a rate limit of 50 calls per minute on each API.

Yes, permissions are required to access the Reporting APIs. They can be found in Suite administration > Roles and permissions > Explore > Reporting APIs. These permissions are split out by product.

You can access Reporting APIs from the following link: Reporting APIs

The Explore dashboards that come with the system will refresh 1-3 times per day. These refreshes can be scheduled in Organization Settings > Explore. You can also initiate on-demand refreshes on this page but there is a maximum of five refreshes per day per dashboard. You need to be an Organization Admin with the organization and have the Project > Access Explore settings permission. The Explore Organization settings page also has an option to kick off an on-demand refresh for each dataset.

Each custom-built dashboard refreshes when the system dashboard it was built from refreshes.

We apply the same project-level security to the dashboards that we do on reports. This means when users access a dashboard, they can only see data for projects they have assignments on.

The dashboard visibility itself is controlled at the Organization level, meaning that when a dashboard has its visibility turned on or off on the Explore Settings page, this applies for the whole organization.

There is an additional InEight Platform permission for Explore that will control a user’s available dashboards, so they only see dashboards that have been shared with them as an individual.

This can be found in the Explore section under Roles and Permissions

Our dashboard release strategy is to deploy dashboards to clients a release before they technically “go-live”, referring to these early releases as “Preview” releases. These Preview releases give you a “sneak peek” and an opportunity to test the new functionality and provide feedback before the dashboards officially go live.

Users can make these dashboards visible by navigating to the Explore Settings page and toggling the visibility from Off to On. This will apply for the whole organization. Note that you will need an additional Platform permission to access the Explore Settings page.

• If you turn on the visibility for a dashboard before it has gone live (as a Preview dashboard), when the dashboard goes live, it will stay visible.

• If you turn the dashboard visibility on and then back off, it will stay hidden when the dashboard goes live.

• If you leave the dashboard visibility set to “Hide” and don’t touch it while it’s in Preview, then the dashboard will become visible upon going live.

You will need the following permissions from Platform > Suite administration > Roles and permissions:

• Explore > API Generator

• For pulling data from the Completions or Compliance application

  • Explore > Reporting APIs > View Completions web APIs

  • Explore > Reporting APIs > View Compliance APIs

You will also need module-level permissions assigned in Compliance or Web Completions.

Due to the complexity of manipulations to get the data in the correct format, data in the APIs is updated daily. The data is therefore staged to avoid running into performance and timeout issues when you access your APIs.

No, this feature is specific only to singular forms.

401: Unauthorized - generated token isn't valid or available

• Try regenerating the authentication token.

404: Resource not found

• APIM has been updated to the latest version and your environment is on a previous version. This will be resolved when your environment is upgraded.

• The API in question has been removed from our codebase, but not APIM. This does not occur often and it will be documented in the Release Notes if it happens.

500: Internal Server Error

• Authentication token isn't valid.

• There could have been a column modification, which will also be documented in the Release Notes.

• Transient/Intermittent Azure related issue.

502: Bad Gateway

• This is a timeout issue. The system has two minutes to run the API query and return data.

• Could be a data volume issue. Try limiting the API call with some kind of filtering.

• Reduce simultaneous calls.