Frequently Asked Questions

Every organization has entities (customers, products, suppliers) duplicated and inconsistent across systems. Rapida MDM 2.0 establishes one governed, approved version of each entity (the golden record), with a clear owner, validation rules, and a full audit history, all inside your Snowflake account.

No. The application runs on Streamlit-in-Snowflake and Snowpark Python, entirely within your account. There are no external servers, no vendor-hosted components, and no copy of your data outside your warehouse.

With their existing Snowflake credentials, the same login used for Snowsight, including SSO where configured. Rapida MDM 2.0 has no separate password store or user directory to maintain.

Three things: a Snowflake account where the application is deployed, a Snowflake user with permission to query the MDM_ONE.CORE schema, and a modern web browser. The Getting Started guide covers the first fifteen minutes.

The approved, trusted master version of an entity, the version downstream systems should consume. Records only become golden through explicit approval, and once golden they cannot be silently changed: every edit creates a new pending version that must itself be approved.

Records move through three states: Draft (being prepared), Pending (awaiting approval), and Golden (approved master). New records land as Pending; approvers promote them to Golden; edits to a Golden record spawn a new Pending version while the original stays protected. Rejection sends a Pending record back to Draft; revocation withdraws trust from a Golden one. Details on the Records page.

The business key is how the platform recognizes that two rows describe the same real-world entity. It drives versioning, blocks duplicate creation in the app, lets imports load matching rows as new pending versions, and powers search. Every table should define its business key before real data arrives; see Attributes.

Almost nothing. Enterprises, data models, tables, and records are all soft-deactivated: hidden from view but preserved and restorable, with their history intact. The one exception is attribute deletion, which is permanent because it changes the table's schema and drops the stored values for that field.

Every action on a record (create, update, approve, reject, revoke) is logged with the user and timestamp, and every version preserves the full set of field values at that point in time. Notification emails are audited too. You can always answer who changed what, when.

Two layers. Global roles (SuperAdmin, Admin, Editor, Viewer) are assigned per enterprise in Settings and govern broad capabilities. Table-level responsibilities (Data Steward, Approver) are assigned per table in Responsibilities and override the global role for those specific tables. A Viewer who is steward of one table can edit that table, and only that table.

On a fresh installation, before any user assignment exists, every authenticated user has full SuperAdmin access so setup is possible. The first assignment created in Settings → Users ends bootstrap mode and switches on strict role-based access. Create a SuperAdmin assignment for yourself first, before anything else, to avoid locking the administrators out.

Through enterprises. Each enterprise isolates its data models, tables, records, and user assignments, and access is granted enterprise by enterprise. Users see only the enterprises they are assigned to; SuperAdmins see all. Even the Dashboard's counters are scoped to the viewer's entitlements.

Yes, deliberately. Golden records are published as Snowflake views (MDM_ONE.CORE.VW_<table>) that anyone with read access to the schema can query. That is the intended integration boundary for dbt, BI tools, and applications. Note this access is governed by Snowflake privileges, so manage grants on MDM_ONE.CORE accordingly.

Three, in increasing order of automation: single-record entry through forms on the Records screen; bulk file import (CSV or Excel) with column mapping and validation via Import & Export; and scheduled inbound syncs from any Snowflake table. All three land records as Pending: governance is never bypassed.

By design: if any row fails validation, the entire batch is rejected. Partial loads are far more expensive to untangle than rejected ones, and master data should never contain half an import. Fix the flagged rows and re-run: nothing was committed, so there is no cleanup.

Preferably through the outbound golden record views, which always reflect the current approved state and include useful system columns (RECORD_ID, CREATED_AT, APPROVED_BY, and so on). For ad-hoc needs, exports to Excel, CSV, or JSON are available, also restricted to golden records.

Schedules are configured and displayed in UTC, so convert from your local time when setting them up. Daily, weekly, monthly, and manual cadences are supported.

Build the canonical model once, ideally in a template enterprise, then use Duplicate Model to copy it into each regional enterprise. Tables, attributes, and reference relationships are copied and remapped automatically. Copies are independent thereafter. See Data Models.

Two mechanisms: the Dashboard sorts tables by urgency so queues are visible at a glance, and the Responsibilities page can send email alerts to a table's assigned team through Snowflake's native email integration, with each alert logged in the audit trail.

Yes. In Settings you can set the application name, upload your logo, and choose from a set of color themes. Branding is platform-wide, so every user sees the same identity.

A sensible sequence: create the first SuperAdmin assignment (ending bootstrap mode); create enterprises for your major boundaries; define data models and tables with business keys; assign stewards and approvers in the Responsibilities matrix; load existing data via import or inbound sync; then let the approval workflow establish your first golden records. Each step maps to one section of this documentation.