# Weekly Fivetran audit of sensitive data in your warehouse

> Every Monday we review what your Fivetran pipelines are copying into the warehouse, flag unmasked personal data in Slack, and open a ticket for each affected pipeline.

- Workflow type: agent
- Services: Fivetran, Slack Bot, Linear
- Categories: Operations, Engineering
- Published: 2026-08-14

## What it does

- Walks every one of your Fivetran pipelines each Monday and looks at which tables and columns are actually being copied into your warehouse.
- Spots fields that look like regulated personal data, such as email, phone, date of birth, national ID, passport, bank and card numbers, salary and free text health or notes fields, then singles out the ones landing unmasked.
- Ignores anything already masked or already switched off, so the Monday message only shows what genuinely still needs attention.
- Posts one prioritized Slack summary grouped by pipeline that names the exact schema, table and column, and opens a Linear ticket per affected pipeline with a recommended fix.

## What you'll need

- A Fivetran account with permission to view your pipelines and their sync settings
- A Slack workspace where the bot can post to your data or compliance channel
- A Linear workspace, and the team these tickets should land on
- Optional: a short list of column names you have pre-approved for automatic masking, if you want the workflow to fix those without asking

## Prompt

Every Monday at 8am, review what my Fivetran pipelines are actually replicating into the warehouse and flag sensitive data that is landing in the clear. This is a governance sweep over pipeline configuration, not a sync health check, so I care about what is being copied rather than whether the last run succeeded.

Start with List Connections to get every connection in the account, then walk them one at a time. For each connection, use Get Connection Schema Config to inspect the full schema, table and column configuration, and determine which tables and columns are enabled for syncing and which are hashed or blocked. Where the schema config does not give enough column level detail for a table, follow up with Get Source Table Columns Config for that specific source table.

Judge each enabled column by its name together with its table and schema context to identify likely regulated or sensitive fields. Treat the following as sensitive: email addresses, phone numbers, date of birth, national ID or SSN, passport and driver licence numbers, bank account and payment card numbers, salary and compensation, and free text health or notes fields. Context matters, so a column called number inside a payment_methods table is a very different risk from number inside a line_items table. Use the table and schema name to disambiguate before you decide.

The finding I care about is a column that is enabled AND not hashed. If a sensitive column is already hashed, or already blocked or disabled, it is fine and should be left out of the report entirely. Suppressing already remediated columns is what keeps the Monday message readable. Do not attempt to diff against previous runs or carry state between weeks, just report the current state of the configuration each time.

Post one Slack Bot message with Send a Message to my data governance channel. Group findings by connection, and order them so the highest risk leads: national ID and SSN, payment card and bank details, and free text health or notes first, then date of birth and passport, then email, phone and salary. For every finding, name the exact schema, table and column so someone can go straight to it without hunting. Open the message with a one line summary of how many connections were reviewed, how many had findings, and how many were clean.

For each connection with at least one finding, use Create Issue in Linear to open one issue on my data team. Title it with the connection name, list every affected column in schema.table.column form, and give each one a recommended fix of either hash or disable. Recommend hash where the field still has analytical value in masked form, such as email or phone used for joins and counts, and recommend disable where the warehouse has no business holding the value at all, such as a passport number or a full card number. Keep it to one issue per connection so each ticket maps to a single owner and a single pipeline.

Do not change any pipeline configuration by default. This workflow is advisory. The single exception is Modify Column Config, which you may use to hash a column only when that column name matches a pattern I have explicitly pre-approved in advance. My pre-approved patterns are: FILL THIS IN, for example columns named exactly email or phone_number. If that list is empty, change nothing at all. Never disable a column automatically, never hash anything outside the approved patterns even when the risk looks obvious, and never modify table or schema level config.

Always close the Slack message by stating plainly what was changed versus what still needs a human decision. If anything was hashed automatically, list it under a Changed automatically heading along with the approved pattern that authorized it. Put everything else under a Needs your decision heading with a link or reference to the Linear issue that tracks it. If nothing was changed, say that explicitly rather than staying silent, so I never have to guess whether the workflow touched production config.

## How to customize

- Change the timing from Monday at 8am, or scope the review to a single group of pipelines instead of the whole account.
- Adjust what counts as sensitive, adding internal categories like customer reference numbers or account IDs that matter in your business.
- Pick the Slack channel and the Linear team, or swap Linear for another tracker your team already lives in.
- Decide whether it stays advisory only, or is allowed to mask a named list of pre-approved columns on its own.

## FAQ

### Will this change my pipeline settings on its own?

No, not by default. It reports and raises tickets, and leaves every decision to you. The one exception is if you give it a list of column names you have pre-approved for masking, and even then it will only mask those exact matches and will say so in the Slack message. It never switches a column off automatically.

### What counts as sensitive data here?

The usual regulated categories: email addresses, phone numbers, date of birth, national ID or social security numbers, passport and licence numbers, bank account and payment card numbers, salary and compensation, and free text health or notes fields. It reads the column name together with the table it sits in, so a vague name like number is judged differently in a payments table than in an orders table. You can add your own categories.

### Will it keep nagging me about the same columns every week?

It only reports columns that are switched on and not masked, so once you mask or disable something it drops off the list for good. Anything still open does reappear, which is the point of a standing weekly check.

### Will it catch new fields that appear in a source system?

Yes. Pipelines often start copying newly added source fields without anyone reviewing them, which is exactly how regulated data quietly ends up in a warehouse. Because this reads your current settings fresh each week rather than comparing against an old snapshot, a field that only just started syncing shows up in the next Monday review.

### Do I have to use Linear?

No. Linear is just the default here because one ticket per pipeline maps neatly to one owner. You can point it at Jira or another tracker instead, or drop the ticket step entirely and keep only the Slack summary.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-fivetran-audit-of-sensitive-data-in-your-warehouse