## Dynamic mapping task lineage

URL: https://docs.atlan.com/apps/connectors/etl-tools/informatica-cdi/concepts/dynamic-mapping-task-lineage

> How Atlan resolves source fields, target fields, and field-level lineage for Informatica CDI dynamic mapping tasks

A [dynamic mapping task](https://docs.informatica.com/integration-cloud/cloud-data-integration/current-version/tasks/dynamic-mapping-tasks.html) can contain multiple jobs, each with different source and target configurations. Atlan resolves lineage individually per job—applying job-specific configurations and resolving parameter values independently.

## How lineage is resolved

Atlan determines source and target fields separately, with each following its own resolution logic based on how the job is configured.

### Source fields

Atlan uses its SQL Parser to extract source fields directly from the parameterized query—but only when the query contains explicit field names. For example, a job where `Source_Table` is set to:

```sql
SELECT HOUSE_NUMBER, FAMILY_NAME, ADDRESS, NUMBER_OF_MEMBERS, YEAR FROM ...
```

The parser extracts each field to build the source field list, then links those fields to the next transformation on a 1-1 name-match basis, mirroring how Informatica CDI executes the mapping at runtime.

| Configuration | Detail | Supported | Fields derived from | Mapping derived from |
|---|---|---|---|---|
| Parameterized Query | SQL query with explicit fields, for example `SELECT col_x FROM tab_1;` | ✅ | Atlan SQL Parser | 1-1 name match to next transformation |
| Parameterized Query | `SELECT * FROM tab_1` pattern | ❌ | — | — |
| Parameterized Single Object | Table name passed as a parameter | ❌ | — | — |

For `SELECT *` queries and parameterized single objects, both field-level and object-level lineage are missing—Atlan can't derive field details from the Informatica API exports for these configurations.

### Target fields

Target field resolution happens in two steps. The Object Type defines the source of fields—if set to **Parameter** or **Single Object**, fields come from the output of the previous transformation. The Field Mapping Type controls how fields are mapped: **Completely Parameterized** derives both the field list and mapping from the parameter expression, resolving values per job, while **Automatic** maps fields by matching names from the incoming transformation.

| Configuration | Detail | Supported | Fields derived from | Mapping derived from |
|---|---|---|---|---|
| Target Object: Parameter / Single Object | Target fields inferred from upstream transformation output | ✅ | Previous transformation | Per the Field Mapping Type setting |
| Field Mapping Type: Automatic | Fields automatically mapped by name from incoming transformation | ✅ | 1-1 name match | 1-1 name match on incoming fields |
| Field Mapping Type: Completely Parameterized | All target fields defined via parameter expression | ✅ | Parameter expression | Parameter expression (resolved per job) |
| Field Mapping Type: Partially Parameterized / Manual | Mix of parameterized and hand-picked fields, or fully manual mapping | ❌ | — | — |

## See also

- [Tasks, transformations, and lineage](https://docs.atlan.com/llms/connectors/informatica-cdi/tasks-transformations-and-lineage/llms.txt): FAQ covering supported task types, transformations, and lineage
- [Transformation logic](https://docs.atlan.com/llms/connectors/informatica-cdi/transformation-logic/llms.txt): How Atlan captures transformation logic and business rules
- [What does Atlan crawl from Informatica CDI](https://docs.atlan.com/llms/connectors/informatica-cdi/what-does-atlan-crawl-from-informatica-cdi/llms.txt): Complete reference of all assets and metadata discovered during crawling

---