Pushing tags back to Snowflake
Write classifications from KRISID onto the warehouse itself — previewed first.
On this page
A classification agreed in KRISID is more useful once Snowflake knows about it too. Snowflake masking policies, row access policies and cost reports can all work from tags. The tag push writes values from KRISID onto your Snowflake objects as tags. You always see a preview first, and nothing is written until somebody presses the button.
It is the only thing in KRISID that changes a source system. It writes tags and nothing else: no views, no comments, no grants, and it never reads a row of your data.
Before you start
- Harvest the Snowflake account first, with an ordinary Snowflake source. The push can only tag objects KRISID has catalogued. See Connections and harvesting.
- Manage sources (CONNECTION_MANAGE) lets you create the push source and say what it writes.
- Run a harvest (HARVEST_RUN) lets you preview a push.
- Push tags to a source (TAG_PUSH) lets you actually write, and approve new tags. In the starter model only Sysadmin has it.
- Snowflake needs a role that is allowed to apply tags (see below).
Create the push source
- On Administration → Sources, press New source and choose Snowflake — push tags.
- Give it a Code and a Name, and choose how it signs in. The ways in are the same as for the reading Snowflake card.
- Under Where to write, fill in the fields described below.
- Press Create source.
| Field | What to put |
|---|---|
| Account | Spelt exactly as on the Snowflake source that harvested this estate. That is how the push knows which assets it may write to |
| Role | The role that does the writing. Use a separate role from the one that harvests |
| Where tags live — database and Where tags live — schema | Where the tag objects are kept, usually a governance database |
| Push only what this saved search finds | Optional. The name of a saved search. Leave it empty to cover everything harvested from this account, or fill it in to push, for example, only one domain |
This card doesn't ask what to bring, or what to do about things that disappear. It reads nothing, so those questions don't apply.
Say what becomes what
On the push source's page, What becomes what holds the mappings. Each line takes one fact KRISID holds and sends it to one Snowflake tag.
- In the first list, choose the fact, for example a classification attribute such as Contains PII, a responsibility such as Data Owner, or a harvested property. The facts come from your metamodel, so your list may differ.
- Type the tag's DATABASE, SCHEMA and TAG_NAME.
- Press Send this to that.
If a tag doesn't exist in Snowflake yet, the line says will not be created. To let KRISID create it, somebody with TAG_PUSH presses May be created. The line then shows who allowed it. Until that happens, everything that needs the tag is held back.
Remove stops a line from being sent in future. Tags already written stay in Snowflake.
Preview, then push
- Press Test connection. It checks the role's grants and says whether a push would work.
- Press Preview the push. You see how many values would be written, how many already say this, and any that cannot be written, each with its reason. Open statement(s), exactly as they would be sent to read every statement.
- When you are happy, press Push tags now, then Write them to confirm.
The run page then shows how many values were written, any tag(s) created, and anything refused by Snowflake with Snowflake's own error. Every line of it → opens the full record.
Important: KRISID never removes a tag. If you clear a value in KRISID, the next run reports it as cleared here, left alone in Snowflake. To remove the tag, someone with the right access must do it in Snowflake itself.
Pushes run only when somebody presses the button. They have no schedule.
What to grant in Snowflake
On the push source's page, open What to ask the administrator for. It holds a script generated from your settings and mappings. Copy it and send it to your Snowflake administrator. In short, it:
- creates a separate role for writing tags;
- grants APPLY TAG on the account, which is the privilege the push depends on;
- grants usage on the database and schema where tags live, and CREATE TAG there if you want KRISID to create approved tags;
- grants usage on the databases whose objects will be tagged, and on a small warehouse;
- optionally lets the role see which tags already exist, so a preview can tell missing tags from existing ones.
It grants no SELECT, no ownership, and nothing that can drop, delete, insert, update or merge.
APPLY TAG on the account is a broad privilege. A role holding it can set or unset any tag on any object it can see. KRISID itself only ever sets tags and creates approved ones. The script also shows a narrower alternative, commented out, with the catch explained: Snowflake then requires the role to own every object it tags.
If you add a mapping that uses a new tag schema, copy the script again. It names the schemas your mappings actually use.
Good to know
- Snowflake objects that can take tags include databases, schemas, tables, views, columns, stages, tasks, functions and more. The account itself is not tagged. A mapping that would land on it is reported as blocked, with the reason.
- A tag value can be at most 256 characters. A longer value is refused, and the run gives the reason.