Debug Inspector
The debug inspector allows you to inspect your data records and transformations made to your data throughout the event stream.
The debug inspector is an important step in the data troubleshooting process. Use the debug inspector if you see unexpected data in your solution. Information in the debug inspector relates to at least one subject attribute, such as Employee ID or Organization Hierarchy ID.
Note: To use the debug inspector, the job that generated unexpected data must have been run with Generate debugging info enabled. For more information, see Schedule a Job.
The debug inspector answers many of your initial questions to accelerate data debugging, including:
- Was data from a particular file ever loaded? This indicates whether the data that you're troubleshooting was correct during a previous data load.
- At what stage in the loading process did a particular value change? Information about the stage can provide more insight about why the value changed, such as by a business rule.
- When did a value change and is that change valid? You can compare the values that were extracted against your own file to determine the validity of a change.
- Why is this person showing as "Unknown" in a group by? You can investigate the data for individual subjects to understand why you’re seeing an unexpected value in visualizations.
- How did these system hire events or system termination events get here? You can look further into any system events that are unfamiliar to you.
- Is this business rule doing what I expect it to do? The debug inspector displays each stage of the event stream which allows you to validate that your business rules are working as expected.
Event stream stages
The event stream has two event streams—main and auxiliary—each of which are made up of stages.
- The main event stream finds values throughout the entire process of loading and transforming data in your solution. A majority of your troubleshooting questions will be answered by the main event stream.
- The auxiliary event stream finds values from lookup mappings, and in some cases you will need to switch back to the main event stream to find additional information.
Tip: Always check the Normalizer stage first! It contains a lot of important information and may provide an answer to your question quickly.
Main event stream
| Stage | Description |
|---|---|
| Normalizer | The data most closely resembles what is present in the original data transfer. Only extraction rules and override behavior are applied at this stage. You can correct errors in the data in this stage. If your data is temporal, profile conception events and profile termination events are generated. |
| Corrections | This stage behaves like the Normalizer stage. This is the last stage before any special logic is applied. If your solution doesn’t contain correction mappings, nothing happens during this stage.
The Corrections stage is a good place to look at relatively unchanged extraction data that is entering into business rules. |
| Business Rules | Each of the specified business rules are applied sequentially in this stage. After each rule, an ambiguity check is performed and any new ambiguity is resolved.
You can step through each business rule in turn to see what is modified. Search for a business rule by using its object name, not display name. Any lookup mappings in the list display one stage per property. If you know something has changed, you can:
|
| System Rules | System rules cannot be changed manually; however, you can change the settings of a system rule to modify its behavior. If events are inexplicably moving around or profiles are starting or ending, look at the system rules stage. In this stage, you can investigate:
|
| Multi-Subject Rules | This is the final stage in the data loading process. The final result should match the values seen in your solution. If you find values here don't match what you see in your solution, you can investigate other rooms in the studio experience. Several default validation rules are applied, even if no multi-subject rules are created. If your tenant doesn't have any multi-subject rules defined, you can still view multi-subject validation rules in this stage. If you know something has changed, you can:
|
Auxiliary event stream
| Stream name | Description |
|---|---|
| The object name of a lookup mapping | The auxiliary stream contains lookup mapping values.
Use the auxiliary event stream to check a value. If the value exists, the mapping key is correct, so the issue comes from something else, such as the business rule. For example, if you have a lookup mapping with a “null” value in the event stream, you may want to investigate the business rule, lookup, or lookup key. |
Debug inspector columns
| Column name | Description |
|---|---|
| Event Type | The type of event that occurred. Event types include:
|
| Data Source | The source of the event. This is based on the type description or a target group of mappings. Sources are split between auxiliary and primary sources. Auxiliary sources affect the properties that are set in the source. |
| Valid Range | System rules use the validity range to determine what the limits are for adjusting event dates based on conception and termination events during the period. This is set automatically for temporal mappings and is blank for transactional mappings.
The Valid Range column can be very important when looking for causes of system hires and terminations. |
| Last Modified By | This indicates what last modified the event. It’s most useful in the Normalizer and Business Rules stages.
When an event is deleted, indicated by a red background, this column has not been updated by the rule that deleted it. It won’t show the object name of the deletion rule, but the latest rule ahead of the deletion rule that modified the property. |