Skip to main content
A saved run is the reusable setup behind every reconciliation — source systems, file types, schemas, and the primary IDs Darpan uses to match records. Creating it takes a few minutes; running it takes one click. Once the setup exists, author its comparison logic in the Ruleset Manager. See Author reconciliation rules.

​
Before you start

Confirm:
  • The two source systems are known.
  • Each source file type is known: CSV or JSON.
  • Saved schemas exist for JSON sources, or you are ready to create them from the setup flow.
  • Each source has a stable primary ID field or expression.
  • The saved run name is clear enough to recognize later from Open Runs Settings, Run Reconciliation, and automation setup.

​
What Darpan saves

​
Steps

1

Open the create flow

Open Ask Darpan with Cmd/Ctrl+K or the floating Ask Darpan button. Search for Create Reconciliation Flow and open the result.
2

Name the saved run

Answer What should this run be called? with a stable, specific name. Add a short description when the flow asks for one.
3

Configure the first source

Choose the system that provides the first file. Then choose the file type.If the first source is JSON, select the saved schema that describes it. If the schema does not exist, use Create New Schema from the setup flow and return after saving it.Choose the primary ID field or enter the primary ID expression that identifies each first-source record.
4

Configure the second source

Choose the system that provides the second file. The second system must be different from the first system.Choose the file type, select the saved JSON schema when needed, and choose or enter the primary ID field for the second source.
5

Create the saved run

On the last primary ID step, choose Create. Darpan saves the run setup so it can be executed manually or reused by an automation.
6

Confirm the setup

Open Ask Darpan, search for Open Runs Settings, and confirm the saved run appears. Use Run Reconciliation when you are ready to execute it once with files or connection-backed data.

​
Comparing two instances of one system

The two sides do not have to be different systems. Comparing one database against another, or one instance of a system against a second instance, is a normal reconciliation — staging against production, or two regional instances that should agree. What Darpan requires is that the two sides are not the same source. Same system with two different source configurations is allowed; the same source on both sides is rejected, because a source compared against itself has nothing to find.
Runs built from direct file uploads keep the stricter rule and still require two different systems. An upload carries no source configuration, so there is nothing to tell two same-system sides apart.
Where both sides are the same system, run results label each side by its source rather than by the system name alone, so the two instances stay distinguishable when you review differences.

​
Choosing an API endpoint

When a source system exposes more than one endpoint, Darpan asks which one to extract from, and lists the endpoints enabled for that source configuration. If only one endpoint is available, the question is skipped — a choice with a single option is not a choice. Endpoints that a source cannot use, and endpoints only reachable through the API rather than a file upload, are filtered out rather than offered and then rejected. Which endpoints a source offers is controlled per source configuration; see Manage users and access.

​
Expected result

The saved run can be selected from Run Reconciliation and from the automation setup flow. It should clearly show what two systems are compared and which record IDs are used for matching.

​
Add comparison rules

The create flow saves the source, schema, and primary-ID setup. The comparison logic, which fields must line up and how, lives in the RuleSet for the saved run. Open the Ruleset Manager for the run to add rules. See Author reconciliation rules.