Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.mantrixflow.com/llms.txt

Use this file to discover all available pages before exploring further.

Production documentation is not complete until it explains what to do when things go wrong. This page covers the operational behaviors most teams hit after their first successful pipeline.

​
Use the Activity Log for org-wide context

The Activity Log shows events across the organization, not just one pipeline. It is the fastest way to answer questions like:
  • Did the run actually start?
  • Was the failure limited to one pipeline or many?
  • Did a connection test fail shortly before pipeline errors began?
  • Was a pipeline deleted or edited by another operator?
Activity log with filters and table

​
The most common edge cases

​
Connection tests fail after a password rotation

Re-open the connection, update the credential, run Test Connection, save, and only then retry the affected pipelines.

​
A source table disappears from the builder

Refresh source metadata or use Discover Tables from the connection. If it still does not appear, check grants on the source schema and table.

​
The pipeline saves but the run fails immediately

Validate the destination configuration. A missing schema, invalid table name, or stale destination credential often surfaces only at run time.

​
The transform preview works but the pipeline run fails

Preview confirms sample-row behavior, not every production edge case. Check the exact run error and tighten the script around null handling, nested objects, or type casting.

​
Someone deletes a connection that a pipeline still needs

Expect broken runs until the pipeline is pointed at a replacement connection. The fix is usually to recreate the connection, edit the destination or source configuration, save, and run manually.

​
Safe change-management checklist

  1. Confirm the active organization.
  2. Test the connection after any credential, network, or SSL change.
  3. Save builder changes before running.
  4. Run manually before re-enabling schedules.
  5. Check both Run History and Activity Log after the change.

​
About warning banners in screenshots

Some screenshots show warnings on purpose. They represent normal operator scenarios such as disconnected credentials or missing dependencies. Treat them as examples of what the failure UX looks like, not as product defects in the docs.