Skip to content
ProFinda Learning

Connecting your data sources · lesson 3 of 3

Diagnosing a sync problem

In this lesson

  • Trace a wrong or stale ProFinda field back to its source system
  • Distinguish a timing problem from a mapping problem from a source-data problem

A field in ProFinda that looks wrong - a team, a skill, an availability window - has a small number of likely causes, and diagnosing which one saves you from the wrong fix, such as editing a field that will simply be overwritten at the next sync.

The three usual causes

  • Timing. The source system changed, but the scheduled sync has not run yet. This resolves itself and needs no action beyond waiting or, if urgent, requesting a manual sync from your platform team.
  • Mapping. The field is being pulled from the wrong source field, or transformed incorrectly during the sync - for example, a Workday grade code showing as a raw number instead of the expected title. This needs a correction to the integration configuration.
  • Source data. The field is genuinely wrong in the originating system - a team assignment that was never updated in Workday, a project end date that finance never closed out. This needs correction at the source, not in ProFinda.

A working method

  1. Check when the relevant integration last synced. If it was before the source system changed, wait for the next scheduled sync or ask your platform team for a manual trigger before assuming anything is broken.
  2. If the sync has run since the change and the field is still wrong, compare the ProFinda field directly against the same field in the source system. If they now match each other but both look wrong, this is a source-data problem.
  3. If ProFinda and the source system disagree even after a confirmed sync, this points to a mapping problem, and belongs with your platform team to review the integration configuration.
  4. Report source-data problems to whoever owns that system - HR for Workday-sourced fields, finance for billing-sourced fields - since a ProFinda-side fix will not hold.

Why this order matters

Checking timing first is the fastest possible resolution, since a large share of “wrong data” reports are simply waiting on a sync that has not run yet. Working through mapping before assuming source data is wrong avoids sending a correction request to an HR or finance team for a problem that is actually in the integration configuration, which wastes their time and delays the real fix. This order - timing, then mapping, then source - resolves most reported problems with the fewest wrong turns.

Key takeaways

  • Most sync problems are one of three kinds - timing, mapping, or bad source data - and each has a different fix
  • Checking last sync time before anything else avoids chasing a problem that will resolve on its own
  • A field that is wrong in the source system will stay wrong in ProFinda until it is fixed at the source
Previous