# Welcome to Sled The All-In-Once Data Governance Solution for Snowflake Sled helps you to find, understand and trust your analytics. We build it for the Snowflake data cloud, because we believe deep integration enables better workflows and allows us to double down on hard platform specific challenges. Sled has two engines: one for metadata, one for metrics. Both work hand in hand to make your analytics scalable and trustworthy. **Data Catalog and Observability - it's meta data management!** * Search everything, from columns in Snowflake to dashboards in Tableau * Discover and observe your data with data profiles * Document your data and visualization assets * Understand data flows down to to the column level (Lineage) * View access rights and manage ownership of your assets **Metric Store - Define once, use everywhere.** * All Calculations should live in one place, your data warehouse. * Define metrics once and consume them with SQL in any other tool. * Discover and document your metrics in the catalog. ![](/files/GpxWCjMhrORiqHCwKmGK) Sled connects directly with your cloud data warehouse. It needs access to the system database and tables of the warehouse (e.g. in `SNOWFLAKE.ACCOUNT_USAGE`). The metadata engine also connects to dbt cloud, Tableau cloud and PowerBI. # Sled for Business Users (Viewer) Modern businesses run on data. With Sled everybody in the organization can find and understand one of your organizations most important assets. Most business users would have the *viewer* role in Sled. As a viewer you will only see things that your data team approved for usage. So you should only find high-quality data assets that can help you drive the business forward. ## Find data Discover data tables, business definitions or curated dashboards from the landing page.
#### Browse curated topics Your data team curated the most import data assets by topics, so you can easily find them, right on the landing page. #### Search If there are too many topics or you look for a specific attribute of a table (e.g. customer address) you can use the search. The search will returns different objects, with the most popular ones ranked at the top. Click into search and you can filter by object type if you are interested in finding e.g. only tables.
## Understand data Get structured and high-quality meta data about your companies most important assets.
* **Documentation:** Each table has a page in the catalog, with a quick description and automatically assigned meta data. Complex or ambigious expressions are explained with Terms that quickly allow you to navigate to the definition or find other places, where `#orders` are used. * **Column Profiles**: You can also drill deeper to the column-level to understand the shape and details of the data. Among other things, you can see column usage, completeness and how many unique values are stored. #### Data Quality For sound data driven decisions, we need good quality data. Checks help you understand the service-level of the data and if there is currently a problem. Learn more about [Checks](/sled-for-data-users-editors/checks).
## Agree on Terms Terms are important common business definitions that allow everybody to agree on important concepts. Click on "Group" at the top right to browse them by topic.
# Sled for Data Users (Editors) Data professionals know dashboards are just the tip of the iceberg. For people who directly work with data, Sled is a powerful tool to find data, understand it, curate it and build trust. Editors can see the same things as Viewers (see [Sled for Business Users (Viewer)](/sled-for-business-users-viewer)) + more technical metadata + can edit almost everything. ## Find data Discover data tables, business definitions or curated dashboards from the landing page.
Data users can browse data by 1\) Technical Tree Structure (left pane) 2\) Curated topics, e.g. for business domains or projects 3\) Searching for something specific and filtering by topic, objects type or object properties (e.g. if something contains PII information or data ownership) ## Understand Data Get structured and high-quality meta data about your all the data in your Snowflake account, and quickly differentiate between your most used & most important assets and your other data.
* **Documentation:** Each table has a page in the catalog, with a quick description and automatically assigned meta data. Complex or ambigious expressions are explained with Terms that quickly allow you to navigate to the definition or find other places, where `#orders` are used. * **Column Profiles**: You can also drill deeper to the column-level to understand the shape and details of the data. Among other things, you can see column usage, completeness and how many unique values are stored. * **Lineage:** Understand where data comes from, how it was created and where it is used down-stream. Read more about [Lineage and Data Flows](/sled-for-data-users-editors/lineage) * **Timeline**: shows updates and usage of this table over time
## Build Data Products Having a bunch of tables somewhere in your Snowflake account is not good enough to enable reliable and scalable business value. Successful data teams think of data with a product mindset. A data product is a self-contained unit of data that serves a specific business or technical purpose. It is owned and managed by a cross-functional team that is responsible for its quality, reliability, and accessibility. To enable that you can document, categorize, check and approve data in your Snowflake to become data products. ### Document Help data users (people or AI) to understand your data to create correct analytics.\ On the table level, we recommend to start each table description with this sentence:\ "*Each row represents ...*" e.g. an order in our online-shop. ``` Each row represents an order in our online-shop. Each row represents a sales opportunity tracked in Salesforce. Each row represents usage KPIs per customer and month. ``` For columns it's often good enough to give a busines label (e.g. Unique Customer ID) and write business formulas for KPIs (e.g. Number of Active Users / Number of Active Companies). {% hint style="info" %} Use the "AI describe" button to automatically use the power of LLMs to generate the documentation and only edit the suggestion. {% endhint %} Read more about [How to document data?](https://www.sled.so/blog/how-to-document-data) ### Categorize While documentation is free text, you can use topics and properties to structure important metadata. It's always recommended to have a property called `owner`. But you could also classify the confidentially of your data, tag PII data or just assign all your data products to a domain topic like `finance`, `product` or `marketing` {% hint style="info" %} As a data engineer categorize your tables directly in Snowflake with [Object Tags](https://docs.snowflake.com/en/user-guide/object-tagging). They will get syned with Sled as properties or topics (click on "sync property values to topics" in Settings). {% endhint %} Use topics to cureate your data into categories you and your business users care about. They are displayed prominently on the landing page and easy to filter by.
### Check Things break. That should be expected, but it's important that you know when it happens that everybody has transparency about the current quality of your data products. In [Checks](/sled-for-data-users-editors/checks) you can easily enable no-code checks that control the basic data quality dimensions and allow you to define custom SQL checks (soon also AI generated) to test custom business logic. ### Approve As soon as, you data is in a good shape, properly documented, categorized and checked, you can approve it, so that everybody knows they are can use it.
Approving things, makes them visible to viewers and promotes their position in Search and on the landing page. That's it for know, if you are interested in more, please reach out to us. :) # Checks Checks control that the data in a table fulfills a defined service level. Checks are mostly used for monitoring data quality dimensions: Completeness, Consistency, Timeliness, Uniqueness, Validity Accuracy. Activated checks are executed on a schedule. ## No-Code Checks * **Volume** controls row count change is stable. No sudden spikes or drops detected. This is a cheap check that should be enabled for all tables. * **Schema Change** violates in the case of incompatible changes in the schema, e.g. a column name or data type is changed that down-stream consumers might rely on. * **Technical Freshness** ensures the data pipeline is running and SQL statements are updating the table. This information is retrieved from the Query-History. * Parameter: Expected freshness in hours, e.g. 24 hours. This would violate if in the last 24 hours (when checking) the table did not get an update (or the upstream tables in case of a View) * **Content Freshness** controls that recent rows are added or updated. * Parameter: Expected freshness in hours, e.g. 24 hours. This would violate if the selected time column has no new values in the last 24 hours. * Split by dimension: e.g. by country, checks that all dimensions have follow the expected freshness. It might e.g. be that data from your German ERP system is on time, but the Italian one is outdated. Without the split, this check would not fail. * **Data Redundancy** checks if there are duplicates in the table according to a set of key columns. * **Null Values** checks the ratio of null values in a column is in an accepted range. * **Accepted Categorical Values** checks all categorical columns keep the same values. Only less than 10 distinct values are counted as categorical values and the column shouldn't have more than 30% null values. * **Stable Numerical Values** checks statistical attributes of numerical columns are stable (min, max, avg, median). ## Custom SQL Checks Custom checks allow monitoring correctness of business logic, multiple column relationships or validate consistency across tables. An SQL check is considered a failure if it returns rows. #### Examples Business Logic: ensure km/h for rows in the car trip table is below 200. This check would fail if a trip could only take place with an average velocity above 200 km/h. ```sql SELECT * FROM db.sh.car_trips WHERE NOT ( distance_km / duration_h < 200 ) ``` Cross Table Consistency: ensure that all model\_id values in car\_trips exist in the car\_models table. ```sql SELECT * FROM db.sh.car_trips WHERE NOT( model_id in ( SELECT id FROM db.sh.car_models )) ``` ## ## Full Table or Delta Check Most tables in a data warehouse are either fully recreated with each run or only update the most current rows. The timestamp column for checks (at the top) reflects this difference to either check the full table every time or only the last 7 days. The timestamp column should track the creation or update time for records in the table, e.g. created\_at, updated\_at. This column will be used to filter data and compare values over time. If no column is selected, checks are always applied to the full table. # Data Profiles show the shape of your data
The first time any users visits a table page, a data profile is generated. This profile can be manually refreshed with `🔄️Profile`.\ \ It generates a sample of 100k rows for every table or view, computes data quality metrics and the data profiles. If it can not compute a profile for a view within 5 minutes it will stop. The sampler is super fast, even for big tables (TBs) the calculation usually completes within 5 minutes. # Lineage and Data Flows The lineage section for an asset shows how data is transformed and used across different assets. It can show e.g. how multiple source tables are joined to create a core table that is then used by multiple BI reports. ## Interpretation Each box represents an assets (e.g. a table, view or report) and each arrow represents a data flow (e.g. transformation or consumption). A box with a solid border is a persisted asset (e.g. table), while a dashed border is a virtual asset (e.g. view). Boxes are color coded based on the schema they are a part of. Arrows that are transformations can be clicked to show more information about the SQL statement that defines the data flow. Gray arrows are past transformations, while a black arrow is a data flow that ran in the last 24 hours. ## Use Cases ### Impact Analysis Understanding all downstream dependencies before making a change can help avoid corrupting assets downstream. ### Refactoring Data Debt A high-level view of data pipelines can help see anti-patterns, e.g.: * Identify duplicated data assets: often core tables are used to create derived data sets that are redundant. Combining derived assets aligns data quality efforts and boosts productivity * Spot circular data flows: a circle happens if a data asset is computed from another asset that uses information from the original asset. This setup leads to complicated update logic that easily leads to data inconsistencies. * Understand if data flows follow your architecture guidelines. E.g.: a good practice is to create marts for data consumers. These marts should not contain heavy data pipelines. ## Field / Column Lineage A deeper level than table to dashboard lineage is field lineage, where a user can track where a single column was coming from, how it was transformed and where it is used downstream. ## Background Every interaction with data in Snowflake happens with SQL queries, e.g.: ```sql CREATE TABLE orders AS SELECT * FROM raw_orders WHERE status != 'canceled' ``` Snowboard parses statements like these to analyze data flows and connects `raw_orders` with `orders` in the lineage graph. ## Limitations **General** * Data transformations that happen outside of Snowflake are not captured. E.g. a python script that pulls data from view `customers`, enriches the data and writes it back to another table `customers_enriched`. In this case no sql statement is used and no connection will be shown. * Both target and source table need to be indexed in Snowboard. E.g. if the Snowboard user does not have privileges to access the source table `raw_orders`. Snowboard will ignore the connection with `orders` until it gets privileges to access `raw_orders`. **Column Lineage** * Transformations that are based on views and use `alias.*` notation in the select statement are currently not supported. * Transformationas that happen in UDTF (user defined table functions) are currently not analyzed * Multistep table creation with temporary tables is not analyzed for column lineage * Column expressions longer than 500 characters can show incomplete lineage # Templates Automate Your Data Catalog Management ### Overview Templates are a powerful feature that allows you to automatically apply consistent metadata, properties, tags, and data quality checks across multiple data assets in your catalog. Think of templates as "rules" that help you manage your data catalog at scale, ensuring consistency and saving valuable time. #### Why Use Templates? * **Save Time**: Apply changes to hundreds of assets in seconds instead of editing each one manually * **Ensure Consistency**: Maintain uniform metadata standards across your organization * **Reduce Errors**: Eliminate manual mistakes by automating repetitive tasks * **Improve Governance**: Enforce data quality standards systematically ### Getting Started #### Who Can Use Templates? Templates are available to users with **Admin** roles. If you need access, please contact your system administrator. #### Accessing Templates 1. Navigate to the **Settings** page from the main menu 2. Scroll down to find the **Templates** section 3. Click on the Templates panel to expand it ### Creating Your First Template #### Step 1: Start Creating a Template Click the **"Add Template"** button to open the template creation dialog. #### Step 2: Name Your Template Choose a descriptive name that clearly indicates what this template does. For example: * "Marketing Department Assets" * "Production Tables Quality Checks" * "Financial Data Ownership" **Note**: Once created, template names cannot be changed, so choose carefully! #### Step 3: Define Your Pattern The pattern (regex) determines which assets your template will affect. This uses a simple dot notation: **Pattern Format**: `database.schema.table` **Examples**: * `PROD_DB.*` - Matches everything in the PROD\_DB database * `.*\.CUSTOMERS` - Matches all tables named CUSTOMERS in any schema * `MARKETING_DB\..*\.FACT_.*` - Matches all tables starting with FACT\_ in the MARKETING\_DB database #### Step 4: Preview Affected Assets After entering your pattern, click **"Evaluate Regex"** to see exactly what will be affected. The system will show you counts for: * Databases * Schemas * Tables * Columns * Functions * Tableau assets (sites, projects, workbooks, views, datasources) * Terms * Metrics **Important**: Always review these numbers to ensure your pattern matches what you expect! #### Step 5: Configure Properties and Tags **Properties** Add any properties you want to apply to the matched assets: * **Owner**: Assign responsibility to specific users * **Description**: Add standardized descriptions * **Custom Properties**: Any additional metadata fields your organization uses **Tags** Add tags to categorize and organize your assets. Tags are useful for: * Marking data sensitivity levels * Identifying departmental ownership * Flagging assets for review * Creating custom groupings #### Step 6: Enable Data Quality Checks Select which automated checks should run on the matched assets: * **Stable Volume**: Monitors for unexpected changes in data volume * **Schema Change**: Detects structural changes to tables * **Technical Freshness**: Tracks when data was last updated * **Content Freshness**: Monitors data content changes * **Data Redundancy**: Identifies duplicate data * **Null Values**: Checks for unexpected null values * **Accepted Categories**: Validates categorical data * **Stable Measures**: Monitors key metrics for stability #### Step 7: Configure Additional Options * **Approve assets**: Automatically publishes matched assets to make them visible to all users * **Overwrite properties**: Replace existing properties instead of adding to them #### Step 8: Save and Apply Click **"Save"** to create your template. The system will immediately apply it to all matching assets. ### Managing Existing Templates #### Viewing Templates Your templates are displayed in a table showing: * Template name * Pattern (regex) used * Edit and delete actions #### Editing Templates 1. Click the **edit icon** next to a template 2. Modify any settings except the name 3. Re-evaluate the regex if you've changed the pattern 4. Save your changes #### Deleting Templates 1. Click the **delete icon** next to a template 2. Confirm the deletion **Note**: Deleting a template removes the template rule but does NOT remove properties or tags that were already applied to assets. ### Common Use Cases #### Use Case 1: Department-Wide Ownership **Scenario**: Assign all marketing data to the marketing team **Template Setup**: * Name: "Marketing Data Ownership" * Pattern: `MARKETING_DB.*` * Properties: Owner = "" * Enable "Approve assets" to make them publicly visible #### Use Case 2: Production Data Quality **Scenario**: Enable quality checks on all production tables **Template Setup**: * Name: "Production Quality Monitoring" * Pattern: `PROD_.*\..*` * Checks: Enable all relevant quality checks * Tags: Add "production", "monitored" #### Use Case 3: Sensitive Data Flagging **Scenario**: Mark all tables containing customer information **Template Setup**: * Name: "Customer Data Security" * Pattern: `.*\.(CUSTOMER|CLIENT|USER).*` * Tags: Add "PII", "sensitive", "restricted" * Properties: Data Classification = "Confidential" #### Use Case 4: Development Environment Labeling **Scenario**: Clearly mark all development databases **Template Setup**: * Name: "Development Environment" * Pattern: `(DEV|TEST|STAGING)_.*` * Tags: Add "non-production", "development" * Properties: Environment = "Development" ### Best Practices #### 1. Test Your Patterns Always use "Evaluate Regex" before saving to verify your pattern matches the intended assets. #### 2. Start Small Begin with a specific pattern and expand it once you're confident it works correctly. #### 3. Use Descriptive Names Your template names should clearly indicate their purpose for other team members. #### 4. Document Your Templates Consider adding a description property to assets affected by templates explaining why they're configured this way. #### 5. Regular Review Periodically review your templates to ensure they're still serving their intended purpose. #### 6. Coordinate with Your Team Communicate template changes to avoid conflicts or confusion among team members. ### Tips and Tricks #### Pattern Writing Tips * **Case Insensitive**: All patterns are case-insensitive, so `PROD` matches `prod`, `Prod`, etc. * **Wildcards**: Use `.*` to match any characters * **Specific Matches**: Use `^` and `$` to match exact names (e.g., `^CUSTOMERS$` matches only "CUSTOMERS") * **Multiple Options**: Use `|` for OR conditions (e.g., `(PROD|PRODUCTION)_.*`) #### Property Management * When "Overwrite properties" is OFF, templates add to existing properties * When ON, templates replace all existing properties of the same type * Properties added by templates show "Managed by Template \[name]" in tooltips #### Performance Considerations * Templates are applied immediately upon saving * Large patterns affecting thousands of assets may take a moment to process * The system prevents duplicate template names automatically ### Troubleshooting #### "Please fill out every field in the form" Ensure you've: * Entered a template name * Provided a valid pattern * Clicked "Evaluate Regex" to validate the pattern #### "Select at least one user to be the owner" When "Approve assets" is enabled, you must specify an owner in the properties section. #### Pattern Not Matching Expected Assets * Check for typos in your pattern * Remember patterns are applied to the full asset path (database.schema.table) * Use the preview feature to test different patterns * Ensure you're using the correct wildcard syntax (`.*` not just `*`) #### Changes Not Appearing * Refresh your browser to see the latest updates * Check that your template was saved successfully * Verify the affected assets in the main catalog view ### Advanced Features #### Combining Templates Multiple templates can affect the same assets. When this happens: * Properties and tags are combined from all applicable templates * If "Overwrite properties" is enabled on any template, the most recently applied template takes precedence * All selected quality checks from all templates are enabled #### Template Scope Templates can affect various asset types in your catalog: * **Database Objects**: Databases, schemas, tables, columns, functions * **Tableau Assets**: Sites, projects, workbooks, views, datasources * **Business Glossary**: Terms and metrics Each asset type may have specific properties and checks available. ### Frequently Asked Questions **Q: Can I rename a template after creating it?** A: No, template names are permanent once created. You'll need to delete and recreate the template with a new name. **Q: What happens when I delete a template?** A: The template rule is removed, but any properties, tags, or checks already applied to assets remain unchanged. **Q: Can multiple templates affect the same asset?** A: Yes, multiple templates can apply to the same asset. Their effects are cumulative unless "Overwrite properties" is enabled. **Q: How do I remove properties added by a template?** A: You'll need to manually edit the affected assets or create a new template with "Overwrite properties" enabled to replace them. **Q: Can I use templates on Tableau assets?** A: Yes, templates work with Tableau sites, projects, workbooks, views, and datasources using the same pattern matching system. **Q: Is there a limit to how many templates I can create?** A: There's no hard limit, but for performance and manageability, it's best to create focused, purposeful templates rather than many overlapping ones. Remember, templates are a powerful tool for maintaining a clean, well-organized data catalog. Used wisely, they can significantly improve your team's efficiency and data governance practices. # Connect with Snowflake ***\~ 20 min to complete*** You need an `ACCOUNTADMIN` user to follow this guide. ## Create a Role and a User This creates a dedicated role and technical user. Replace `example_wh` with your preferred warehouse. `XS` is enough for most installations. It is ok to share this warehouse with other workloads to save costs. **Set a secure password.** ```sql create role snowboard_role; create user snowboard_user password = '' -- remember that! default_warehouse = example_wh -- specify your warehouse default_role = snowboard_role default_namespace = snowboard comment = 'Technical User for Sled 🛷'; grant role snowboard_role to user snowboard_user; --allow usage of your warehouse grant usage on warehouse example_wh to role snowboard_role; ``` ## Create the Snowboard Database This database will be used to store profiling results and the parsed query log. You can easily access it for your own analytics. Data ownership is great. ```sql create database snowboard; grant ownership on database snowboard to role snowboard_role; ``` ## Grants Read Access to Data For each database that should be added to the data catalog execute these statements. Replace `example_db` with the correct name. You can add more databases later, have at least one to get started. \\ ```sql set db_name = 'example_db'; -- specify name of database grant usage on database identifier($db_name) to role snowboard_role; grant usage on all schemas in database identifier($db_name) to role snowboard_role; grant usage on future schemas in database identifier($db_name) to role snowboard_role; grant select, references on all tables in database identifier($db_name) to role snowboard_role; grant select, references on future tables in database identifier($db_name) to role snowboard_role; grant select, references on all views in database identifier($db_name) to role snowboard_role; grant select, references on future views in database identifier($db_name) to role snowboard_role; grant select, references on all materialized views in database identifier($db_name) to role snowboard_role; grant select, references on future materialized views in database identifier($db_name) to role snowboard_role; ``` 💡If your Snowflake account was created before 2020, also execute the following script:[Grant permissions on future tables](/snowflake_connection/grant-permissions-on-future-tables) For shared databases the following statement is enough. Replace `external_db` with the correct name. ```sql grant imported privileges on database external_db to role snowboard_role; ``` ## Grants Read Access to Account Information Grant access to the query log and further meta data from Snowflake. ```sql grant imported privileges on database snowflake to role snowboard_role; ``` ## Grant right to enable Single-Sign-On Allow the technical user to create a single-sign-on integration. ```sql GRANT CREATE INTEGRATION ON ACCOUNT TO ROLE snowboard_role; ``` ## Network Access If you restrict network access with network policies you can use the following IP addresses for Sled. * 3.210.43.243 * 3.66.185.175 Create a network policy ```sql CREATE NETWORK POLICY snowboard_network_policy ALLOWED_IP_LIST = ('3.66.185.175', '3.210.43.243'); ``` Apply the policy to the role ```sql ALTER ROLE snowboard_role SET NETWORK_POLICY = snowboard_network_policy; ``` # Grant permissions on future tables The following code block grants future permission to the role `snowboard_role` on all future tables and views in a database. This is needed for older Snowflake installations that only support future grants on the schema level. ```sql EXECUTE IMMEDIATE $$ -- TODO CHANGE database_name DECLARE database_name TEXT := 'EXAMPLE_DB'; log_text TEXT; grant_statement TEXT; schema_name TEXT; res_schemas RESULTSET; res resultset; BEGIN log_text := 'START - '; grant_statement := 'show schemas in database ' || :database_name; res_schemas := (EXECUTE IMMEDIATE :grant_statement); FOR record IN res_schemas DO IF (record."name" != 'INFORMATION_SCHEMA') THEN schema_name := :database_name || '.' || record."name"; grant_statement := 'grant select, references on future tables in schema ' || schema_name || ' to role snowboard_role; '; res := (EXECUTE IMMEDIATE :grant_statement); grant_statement := 'grant select, references on future views in schema ' || schema_name || ' to role snowboard_role; '; res := (EXECUTE IMMEDIATE :grant_statement); log_text := log_text || record."name" || ' GRANTED - '; END IF; END FOR; RETURN log_text; END; $$; ``` # Background Tasks for Snowflake These background tasks can run on a schedule. ## Discover Tables This task should run often as it refreshes the meta data of your tables (e.g. every hour). It does not start a warehouse. It discovers tables, views, external tables and materialized views. ## Parse Query Log This task also starts a warehouse. Running it every 8 hours or daily is a good default. The query parser is responsible for the timeline, usage statistics and lineage. If your query history is really big this can take some time to complete. This task also extracts information from other system tables that track e.g. how often materialized views get updated. ## Sync Meta Data to Snowflake This task starts a warehouse. Running it daily is a good default. This job writes back important meta data to Snowflake. Which enables you to create custom analysis on top of your meta data. It also writes back user activity data to track how useful Sled is in your organization. # Configure Paths for Snowflake Background Tasks Paths define which tables and views the discovery task or profiler task should work on. All paths need to be valid [regular expressions](https://docs.python.org/3.8/library/re.html#regular-expression-syntax). The regex is not case sensitive. [(see examples)](#examples) ## Discovery Paths This controls, which objects should be available in the catalog and for the other tasks. **Include:** These data objects (databases, schemas, tables, views) will be indexed for the catalog. `` includes everything. If multiple paths are specified, all of them are searched. Overlapping paths will only be indexed once. **Exclude:** These objects are excluded from the catalog. `` excludes nothing. An object in the excluded paths will always be excluded (even if it was included above). ## Examples ### Match all tables or views of a database ``` demo_db\..* ``` This would match all objects that start with `DEMO_DB.`. Please note that the `.`(dot) needs to be escaped otherwise it matches every character. ### Match all tables or views with certain names Match all tables or views of a schema that start with `my_` and end with `deprecated` ``` my_database\.with_schema\.my_.*deprecated ``` It would match e.g. `MY_DATABASE.WITH_SCHEMA.my_temporary_table_deprecated`. # Enabling SSO on Snowflake ## Automatic deployment ***\~ 5 min to complete*** ### Grant correct rights You need to grant `CREATE INTEGRATION` to the Snowflake role of your configured Snowboard technical user. If you have followed the setup procedure in this documentation you can add these rights with: ```sql GRANT CREATE INTEGRATION ON ACCOUNT TO ROLE snowboard_role; ``` ### Enable SSO Logged into Snowboard as admin user, click the `Enable SSO Button` on the corresponding account on the Snowboard settings page. ## Manual deployment ***\~ 15 min to complete*** You need an `ACCOUNTADMIN` user to follow this guide. ### Create security integration Create a custom security integration by running the following query. Replace {{origin}} with the domain and protocol your Snowboard installation is running and {{host\_name}} with the Snowflake account name. ```sql CREATE SECURITY INTEGRATION SNOWBOARD type = oauth enabled = true oauth_client = custom oauth_client_type='CONFIDENTIAL' OAUTH_ALLOW_NON_TLS_REDIRECT_URI = true oauth_redirect_uri='{{origin}}/api/auth/snowflake/callback/{{host_name}}'; ``` ### Add data to Snowboard Logged into Snowboard as admin user, click the `Enable SSO Button` on the corresponding account on the Snowboard settings page. You will get a warning that your user doesn't have correct rights to automatically enable SSO. Enter the correct information from Snowflake by extracting the data from the following queries: ```sql DESCRIBE SECURITY INTEGRATION SNOWBOARD; ``` This query conveys the data for: * Authorization Endpoint * Token Endpoint * Redirect URI ```sql SELECT d:OAUTH_CLIENT_ID::text as OAUTH_CLIENT_ID, d:OAUTH_CLIENT_SECRET::text as OAUTH_CLIENT_SECRET FROM (SELECT parse_json(SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('SNOWBOARD')) as d); ``` This query conveys the data for: * Client-ID * Client Secret After entering the correct information save the configuration by pressing the `Save Button` # Single Sign-On Authenticate with your existing identity provider Sled supports Single Sign-On (SSO), allowing your users to authenticate using their existing identity provider credentials instead of managing separate passwords. ## Supported Providers * [Azure Active Directory](/sso/azure-active-directory) - Microsoft Entra ID (OAuth 2.0 / OpenID Connect) ## How SSO Works in Sled When SSO is enabled, users see a **"Sign in with Microsoft"** button on the login page. Clicking it redirects them to your identity provider for authentication. After successful login, users are automatically created in Sled and assigned a role based on their group memberships. ### Key Features * **Automatic user provisioning** - Users are created in Sled on first login, no manual setup needed * **Group-based access control** - Map identity provider groups to Sled roles (Admin, Editor, Viewer) * **Default viewer access** - All authenticated users get read-only access without any extra configuration * **MFA support** - Works with your identity provider's Multi-Factor Authentication policies * **Optional password fallback** - Keep password login enabled alongside SSO during transition # Azure Active Directory Single Sign-On with Microsoft Entra ID (Azure AD) ## Integrating Single Sign-On (SSO) with Azure AD for Sled Sled integrates with Azure Active Directory (Microsoft Entra ID) using OAuth 2.0 / OpenID Connect. This guide walks through the setup process for both the Azure AD and Sled sides of the configuration. ### Technical Overview | Property | Value | | ------------ | ----------------------------------------------------------------- | | Protocol | OAuth 2.0 / OpenID Connect | | Scopes | `openid`, `profile`, `email`, `User.Read`, `GroupMember.Read.All` | | Redirect URI | `https://{your-sled-domain}/api/auth/azure/callback` | | Tenant type | Single tenant | *** ## Part 1: Azure AD Configuration ### Step 1: Register a New Application 1. Go to the **Azure Portal** and navigate to **Azure Active Directory** > **App registrations** 2. Click **New registration** ### Step 2: Application Registration 1. Enter the name of the application, e.g. `Sled` 2. Under **Supported account types**, select **"Accounts in this organizational directory only"** (Single tenant) 3. For the **Redirect URI**, select **Web** and enter: `https://{your-sled-domain}/api/auth/azure/callback` 4. Click **Register** ### Step 3: Copy Application IDs Once registered, you will be redirected to the application overview page. Copy and save these two values: * **Application (client) ID** * **Directory (tenant) ID** ### Step 4: Create a Client Secret 1. In the application menu, click **Certificates & secrets** 2. Click **New client secret** 3. Set a description (e.g. `Sled SSO`) and an expiration (12 or 24 months recommended) 4. Click **Add** 5. **Immediately copy the secret Value** (not the Secret ID) - this is only shown once ### Step 5: Configure API Permissions 1. In the application menu, go to **API permissions** 2. Click **Add a permission** > **Microsoft Graph** > **Delegated permissions** 3. Add the following permissions: | Permission | Purpose | Admin Consent | | ---------------------- | ----------------------------------------------- | ------------- | | `User.Read` | Read the signed-in user's profile (email, name) | No | | `GroupMember.Read.All` | Read the signed-in user's group memberships | Yes | 4. Click **Add permissions** 5. Click **Grant admin consent for \[Your Organization]** and confirm {% hint style="info" %} Granting admin consent for `GroupMember.Read.All` requires Global Administrator or Privileged Role Administrator rights. {% endhint %} *** ## Part 2: Azure AD Groups and Role Mapping Sled uses Azure AD Security Groups to control access levels. This section explains how the mapping between Azure AD groups and Sled roles works. ### How It Works 1. When a user logs in via Azure SSO, Sled queries the Microsoft Graph API for the user's group memberships 2. Sled checks the user's groups against the configured group mappings 3. The **highest-privilege matching group** determines the user's role 4. If none of the user's groups match, the user gets **Viewer** access (read-only) 5. Group memberships are checked fresh on every login - changes in Azure AD take effect on the next login ### Sled Roles | Role | Permissions | | ---------- | -------------------------------------------------------------------- | | **Admin** | Full access: settings, user management, edit data, read data, search | | **Editor** | Edit data, read data, search | | **Viewer** | Read-only: browse data and search (default for all SSO users) | ### Step 6: Create Security Groups (Optional) {% hint style="info" %} This step is **optional**. Without any group configuration, all authenticated Azure AD users automatically receive Viewer (read-only) access in Sled. Only create groups if you need to grant Editor or Admin permissions. {% endhint %} 1. Navigate to **Azure Active Directory** > **Groups** 2. Click **New group** 3. Create groups as needed: | Group Name | Group Type | Membership Type | Description | | -------------- | ---------- | --------------- | ---------------------------------- | | `Sled Admins` | Security | Assigned | Full administrative access to Sled | | `Sled Editors` | Security | Assigned | Can edit and review data in Sled | 4. For each group, open the group and copy the **Object ID** from the Overview page ### Step 7: Assign Users to Groups 1. Open each group in **Azure Active Directory** > **Groups** 2. Go to **Members** > **Add members** 3. Search for and select the users who need the respective access level 4. Click **Select** Users not assigned to any Sled group can still log in and will receive Viewer access by default. ### Step 8: Restrict Application Access (Optional) To limit which users can use Sled SSO (rather than allowing all users in your tenant): 1. In Azure, go to **Enterprise applications** and find your Sled application 2. Go to **Manage** > **Users and Groups** 3. Click **Add user/group** and assign the users or groups that should have access 4. Go to **Manage** > **Properties** 5. Set **Assignment required?** to **Yes** - now only explicitly assigned users can authenticate *** ## Part 3: Sled Configuration ### Step 9: Configure Azure SSO in Sled 1. Log into Sled as an **admin user** 2. Navigate to **Settings** (gear icon) 3. Scroll to the **Azure SSO Configuration** section 4. Fill in the fields: | Field | Value | | ------------------------- | ---------------------------------------------------- | | **Tenant ID** | Directory (tenant) ID from Step 3 | | **Client ID** | Application (client) ID from Step 3 | | **Client Secret** | Secret value from Step 4 | | **Redirect URI** | `https://{your-sled-domain}/api/auth/azure/callback` | | **Enable Azure SSO** | Enabled | | **Enable Password Login** | Enabled (recommended during initial setup) | 5. Click **Save Configuration** ### Step 10: Configure Group Mappings in Sled After enabling Azure SSO, the **Azure AD Group Mappings** section appears below the SSO configuration. 1. Click **Add Mapping** 2. Fill in: * **Azure AD Group ID**: The Object ID of the Azure AD Security Group (UUID format) * **Azure AD Group Name**: A friendly label for your reference (e.g. "Data Engineering") * **Sled Role**: Select Admin, Editor, or Viewer 3. Click **Save** 4. Repeat for each group you want to map #### Example Configuration | Azure AD Group | Group Object ID | Sled Role | | -------------- | ------------------- | --------- | | Sled Admins | `a1b2c3d4-e5f6-...` | Admin | | Data Engineers | `e5f6a7b8-c9d0-...` | Editor | | BI Analysts | `1a2b3c4d-5e6f-...` | Editor | With this setup: * Members of "Sled Admins" get **Admin** access * Members of "Data Engineers" or "BI Analysts" get **Editor** access * All other authenticated Azure AD users get **Viewer** access * A user in both an Admin and an Editor group gets **Admin** (highest privilege wins) *** ## Testing ### Test SSO Login 1. Log out of Sled 2. On the login page, click **"Sign in with Microsoft"** 3. Authenticate with your Azure AD credentials (MFA if enabled) 4. After authentication, you should be redirected back to Sled and logged in 5. Check your assigned role in your user profile (top right) ### Verify Group-Based Roles 1. Log in with a user in a mapped Admin group - verify they have Admin access 2. Log in with a user in a mapped Editor group - verify they have Editor access 3. Log in with a user not in any mapped group - verify they have Viewer access *** ## Troubleshooting ### "Failed to exchange code for token" Client secret is incorrect or expired. Verify the secret in Sled matches Azure Portal. If expired, create a new one and update the Sled configuration. ### "Failed to get user information from Microsoft Graph" Missing API permissions or admin consent not granted. Go to App registration > API permissions and verify `User.Read` and `GroupMember.Read.All` are present and granted. ### "Redirect URI mismatch" The redirect URI in Azure does not match the one configured in Sled. Verify both match exactly, including protocol (https) and path (`/api/auth/azure/callback`). ### User has the wrong role 1. Verify the user's group membership in Azure AD 2. Check that the group's Object ID matches the mapping in Sled Settings 3. Have the user log out and log in again (roles are refreshed on each login) ### Group changes not taking effect Azure AD group changes can take a few minutes to propagate. Have the user wait a few minutes, then log out and log in again. Sled fetches group memberships fresh on every login. *** ## Optional: Disable Password Login Once SSO is working reliably: 1. Go to **Settings** > **Azure SSO Configuration** 2. Set **Enable Password Login** to **Disabled** 3. Click **Save** {% hint style="warning" %} Keep at least one admin account with password access as backup before disabling password login. {% endhint %} *** ## FAQ **Can users still use passwords after enabling SSO?**\ Yes, by default both methods work simultaneously. Disable password login in Settings once SSO is stable. **What happens if a user is in multiple mapped groups?**\ The highest-privilege role wins (Admin > Editor > Viewer). **What if no group mappings are configured?**\ All authenticated Azure AD users get Viewer (read-only) access automatically. **Does it work with MFA and Conditional Access?**\ Yes. Any MFA or Conditional Access policies in your Azure AD tenant are enforced during the Microsoft login step. No special configuration needed in Sled. **How do I find a group's Object ID?**\ Azure Portal > Azure Active Directory > Groups > click the group > Object ID is in the Overview tab. **How quickly do group changes take effect?**\ Users need to log out and log in again. Sled fetches group memberships fresh on each login. Azure AD may take a few minutes to propagate group changes. # Other Integrations # Tableau Connect with Tableau to 1\) find and document important workbooks 2\) see lineage from tables to workbooks or columns to visualizations 3\) get an overview of what is most used ## Connection Settings Both Tableau Online or Tableau Server (2019.3 or later) are supported. ### Tableau Online **Connection** Hostname expects the url of the online instance. Site expects the site name. ![](/files/OmNoV2uwevMCf3rqrFBp) **Authentication** Generate a Personal Access Token with a user who is either "Site Admin Explorer" or "Site Admin Creator". 1. Open “My Account Settings“ 2\. Go to the section “Personal Access Tokens” ![](/files/LcFBHpB7q7WlfVZgzhN5) 3\. Create new token with name “**sled**” ![](/files/8bIVWTPR4d5aZgDCYyIX) 4\. Copy token secret to clipboard and save it. This token is valid for 1 year and will need to be refreshed. Alternatively Username and Password can be used if no MFA is enabled. ### **Tableau Server** For connecting from the Cloud with Tableau server, please coordinate with our customer success team . A typical network setup uses OpenVPN or AWS PrivateLink. Make sure the meta data API is enabled. # PowerBI ## PowerBI App Registration, Permission Go to Azure AD App registration, add “New registration” ![](/files/TewzWccY2grIPf8KHoda) Default selection is fine, add a name ![](/files/IUJ2IGkgM7JAmXMyWf5m) Write down Application (Client ID) ![](/files/ow6M2tBB2RMha1Fb11xN) Add a client secret, change the duration to an appropriate amount. Client secret has to be recreated each time it runs out and must also be changed in Snowboard afterwards ![](/files/dngokwtJKeCH8gLzzwC4) Write down Value, this is the Client secret for Snowboard ![](/files/9buTXSM2RTqXD0yOIZTB) Go to API permissions ![](/files/K7FFBKuVUcUPTMQVmEZj) ``` Add “Application Permissions” → “Tenant.Read.All” Add “Application Permissions” → “Report.Read.All” Add “Application Permissions” → “Report.ReadWrite.All” ``` ![](/files/ogeNXL2A48S6eaNVwMUj) Grant admin consent ![](/files/3bWp5OAFaUWyDLlNkaRH) Get AzureAD Tenant ID () ![](/files/3AmboOrnwLsPBpzvMJY9) **Shouldn’t be necessary, but for completeness sake:** Go to [https://login.microsoftonline.com/{tenant-id}/adminconsent?client\_id={client-id](https://login.microsoftonline.com/%7Btenant-id%7D/adminconsent?client_id={client-id)} and grant permissions ![](/files/9KnVKhzhwfsoP1GpWNKx) Today Admin endpoints needed `https://api.powerbi.com/v1.0/myorg/admin/groups` # Qlik ## Introduction Sled, a comprehensive data cataloging tool for Snowflake, now supports integration with QlikSense Cloud. This integration enables users to visualize lineage between QlikSense assets and Snowflake objects, facilitating enhanced data governance and discovery. ## Features and Benefits The QlikSense Cloud integration with Sled offers: 1. Lineage with Snowflake objects: Visualize relationships between QlikSense assets and Snowflake tables, views, and databases. 2. Metadata syncing: Automatically synchronize QlikSense assets, including Apps, Worksheets, and Spaces, to maintain up-to-date metadata. ## Connecting QlikSense Cloud to Sled #### QlikSense Cloud Configuration 1. Open QlikSense Cloud in a web browser. 2. Navigate to the Qlik Admin section. 3. Click on OAuth. 4. Create a new OAuth web client named Sled. 5. Define the following scopes: * `admin.apps` * `apps` * `admin.data:export` * `spaces.shared` * `spaces.managed` * `spaces.data` * `users` 6. Check Allow Machine-to-Machine (M2M). 7. Click Save. 8. Note the generated Client ID and Client Secret.
9. Click the three dots (...) on the far right and select Change consent method, then choose Trusted.
#### Sled Configuration 1. Go to the Sled Settings page. 2. Navigate to Integrations and select Qlik Cloud as the new integration. 3. Enter your Tenant URL as the server.
4. Enter the Client ID and Client Secret noted from the QlikSense Cloud configuration. 5. Click Test Connection and if its successful then Click Save Account ## Verification Once connected, verify the integration by: 1. Click the sync button to start the syncing job 2. Checking QlikSense asset metadata in Sled. 3. Visualizing lineage between QlikSense assets and Snowflake objects. ## Troubleshooting For any issues or concerns, refer contact support. By following these steps, you'll successfully integrate QlikSense Cloud with Sled, unlocking enhanced data governance and discovery capabilities. # Looker ## Create API keys 1. Go to your Looker dashboard: . 2. Click **Admin > Users** in the menu bar.
3. Click **Edit** next to a user.
4. Click the **Edit Keys** button next to API Keys.
4. Click **New API3 Key**.
5. Copy the **Client ID** and **Client Secret**.
## # dbt ## dbt cloud ## Enabling API access 1. Navigate to dbt Cloud: 2. Go to **Account Settings** ![](/files/oRdcgN79MrVAuHrWFYZK) 3. Click the button **Enable Metadata Access**
**Retrieving Service Account Token** 4. Click on your profile icon **> Account Settings** ![](/files/lGPlBYJvBz6kQbQL0Y5R) 5. Click **Service Tokens**. Then click **New Token**
6. Enter a token name, like Metaplane. Then click **+ Add** and select the **Job Admin** permission set for **All Projects**. Lastly, click **Save** in the bottom right hand corner to create the service token. 7. Once you click **Save**, you will be provided a service token. This is what Sled will use to start monitoring your dbt projects. ## dbt core Connecting Sled with DBT Core involves the following steps: **Step 1: Verify Data Objects Availability in Sled Data Catalog** Before connecting Sled with DBT Core, make sure that the data objects you want to work with are available in Sled's Data Catalog. If they are unavailable, follow these steps: 1. **Allow Permissions:** If the objects are unavailable, you may need to allow the necessary permissions in your Snowflake accounts. The guide for this step is available [here](https://docs.sled.so/snowflake_connection#grants-read-access-to-data). 2. **Sync Data Objects:** Once the permissions are granted, sync the data objects from the Settings page in Sled. To do this, go to the Settings page by clicking on your username initials at the top right corner of the page, select "Integrations" from the right navigation, find your connected Snowflake account, and open the Schedule Background Tasks tab. Then, click the "Start Now" button next to the "Discover Tables" option. 3. **Wait for Discovery:** Once the background discovery task is completed, you should be able to find your data objects in Sled's Data Catalog. **Step 2: Deploy dbt Artifacts Package** To deploy the DBT artifacts package, follow these steps: 1. **Download Package**: Download the DBT artifacts package from the official GitHub repository at [Sled DBT Artifacts](https://github.com/Snowboard-Software/dbt_artifacts). 2. **Deploy Package:** Deploy the package to your DBT environment. ```yaml packages: - git: "https://github.com/Snowboard-Software/dbt_artifacts.git" revision: 2.2.8 ``` **Step 3: Connect db Core to Sled** To connect DBT Core to Sled, follow these steps: 1. **Access Settings:** Go to the Settings page by clicking on your username initials at the top right corner of the page. 2. **Select Integrations:** From the right navigation, select "Integrations." 3. **Add Integration:** Click the "Add Integration" button, and select "DBT Core" from the list of available integrations. 4. **Enter Details:** Enter your details, such as your snowflake hostname, database, and schema name which contains your DBT models 5. **Test Connection:** Click the "Test Connection" button to ensure that the connection is successful. đź’ˇ **The sync process will occur automatically as defined in the settings, which can also be updated.** **Step 4: Find Data Objects Tagged Under the dbt\_core tag** Once the process is completed, you can find your data objects tagged under the dbt\_core tag in Sled's Data Catalog. đź’ˇ **All the dbt tests and their status will be reflected on the data objects tagged under dbt\_core in Sled's Data Catalog.**