When DB2 actions are native vs manual review
Not every database action needs the same treatment. The safe dividing line is whether the source pattern looks like a table or row operation that the native connector already understands, or a richer query that depends on joins, aggregates, or product-specific SQL features.
What counts as a good native DB2 candidate
Simple get-row, get-rows, insert, update, delete, and get-tables patterns are good native candidates because the DB2 connector already expresses those shapes directly. If the workflow is effectively reading or writing one table with a straightforward filter, native DB2 is the safest target.
These patterns also make it easier to generate real connector references and cleaner imported flows.
- Single-table lookups
- Simple filters by key
- Straightforward insert, update, and delete operations
- Table-discovery style metadata reads
What still deserves manual review
Once the source query relies on joins, aggregates, CASE logic, RRN calls, or other vendor-specific SQL behavior, the question stops being 'is this a database step' and becomes 'can this exact query be represented honestly by the native connector'. In many cases the right answer is no, not generically.
That is why complex database patterns should remain partial or manual-review even if simple DB2 actions are now supported natively.
Why this line matters
Being honest about the line between native connector coverage and manual review makes the product more trustworthy. A workflow with ten simple row operations and one complex reporting query should not be reported the same way as a workflow that is entirely native-ready.
Native where safe, partial where necessary, is the right rule.