Read each result field in context
The change count describes rows changed by the write; it is not necessarily the number of rows returned. For example, an UPDATE can complete without error yet affect zero rows because its WHERE condition matched nothing. Treat that as a valid execution result and decide whether zero changes are expected for your operation.
An inserted row ID is useful only when the statement creates a row and the database can provide its generated identifier. Do not treat it as the ID of every row changed by an update or delete. When later steps depend on it, check that the insert actually occurred and pass the value from the execution result rather than guessing.
Use the result to design reliable follow-up steps
For a workflow, branch on the returned values when the business process depends on whether a write changed data. A zero-change result may call for a not-found path, while a positive count can continue to a confirmation or notification step. Keep the SQL condition specific so the result reflects the intended record.
Database execution status alone does not validate the business meaning of the write. Use transactions or a deliberate sequence where related changes must succeed together, and avoid reporting success to a person until you have checked the fields relevant to that outcome. Record the result in run history for troubleshooting.