> For the complete documentation index, see [llms.txt](https://docs.dataplex-consulting.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dataplex-consulting.com/data-catalog/rosterguard-app/quickstart.md).

# Quickstart

From install to your first reviewed screen in about 15 minutes.

{% hint style="info" %}
**Prerequisites:** a Snowflake role that can install Marketplace apps, and SELECT on the roster table you want to screen. Nothing else: installing requires no account‑level privileges, the app makes no external calls, and it reads nothing in your account until you connect a roster table in step 3.
{% endhint %}

## 1. Install the app

Get RosterGuard from the Snowflake Marketplace and install it into your account. When the install finishes, open the app from **Data Products → Apps** in Snowsight. You'll land on the **Roster setup** page.

> **Want to try it before connecting your own data?** The app includes a built‑in demo roster: **120 synthetic providers (no real people) with 10 planted matches (2 Strong, 4 Likely, 4 Possible)**. Choose **Use demo roster** in step 3 and skip to step 5.

## 2. Grant your team access

The app installs with two roles you grant to your team:

| Role           | For                 | Can                                                                         |
| -------------- | ------------------- | --------------------------------------------------------------------------- |
| **app\_user**  | Reviewers, analysts | Run screens, work the review queue, export                                  |
| **app\_admin** | Admins              | Everything above, plus connecting a roster, mapping columns, and scheduling |

Your Snowflake admin grants these to existing roles, one statement each:

```sql
GRANT APPLICATION ROLE <app_name>.app_user  TO ROLE <your_reviewer_role>;
GRANT APPLICATION ROLE <app_name>.app_admin TO ROLE <your_admin_role>;
```

{% hint style="info" %}
`<app_name>` is whatever your admin named the app at install. If you're a reviewer reading this, forward this step to your Snowflake admin.
{% endhint %}

## 3. Connect your roster (Roster setup, step 1)

On the Roster setup page, choose **Connect your roster**. **Snowflake's grant dialog opens**: pick the table or view holding your provider roster and grant **read‑only SELECT on that one object**. The app can see nothing else in your account, and you can revoke or reconnect at any time. Once you save, RosterGuard confirms the connection and shows the table you picked, then a **Continue to mapping** button takes you to step 2.

Your roster works as‑is: any table with one row per provider. If your provider data is spread across HR, credentialing, and scheduling systems, a simple view that unions them into one row per provider is enough; you don't need a master‑data project to start. For the strongest matching it should have **last name, first name, and date of birth** (required), plus **NPI** (recommended) and **license state** (optional).

**Roster shape** (one row per provider):

| Column        | Type         | Required    | Notes                                                                                                         |
| ------------- | ------------ | ----------- | ------------------------------------------------------------------------------------------------------------- |
| last name     | TEXT         | Yes         |                                                                                                               |
| first name    | TEXT         | Yes         |                                                                                                               |
| date of birth | DATE or TEXT | Yes         | A DATE, or a parseable string (ISO `YYYY-MM-DD` is safest). This is the gate for Likely (name + DOB) matches. |
| NPI           | TEXT         | Recommended | 10‑digit identifier; store as **text** so it isn't numerically coerced.                                       |
| license state | TEXT         | Optional    | Two‑letter code.                                                                                              |

Sample row:

```
LAST_NAME | FIRST_NAME | DATE_OF_BIRTH | NPI        | LICENSE_STATE
SMITH     | JANE       | 1979-03-14    | 1234567890 | TX
```

**Prefer to try it first?** Choose **Use demo roster** on the Roster setup page to map, screen, work the review queue, and export end to end, exercising every confidence level, before you connect any real data.

## 4. Map your columns (Roster setup, steps 2–3)

Step 2 shows your roster's columns next to the fields RosterGuard matches on. Pick the column for each field; live coverage indicators show how usable each one is (e.g. "DOB parseable 96.7%").

<figure><img src="/files/03r07wsooZ7DZnwcyB7V" alt="RosterGuard column mapping with live per-field coverage indicators"><figcaption></figcaption></figure>

The mapping step shows per‑field coverage as you map, so you know before the first screen whether your roster supports the Likely (name + DOB) matches, not after.

**Why DOB matters:** date of birth is what makes name matching precise: it divides the chance‑collision space by roughly 15,000. If fewer than 80% of your rows have a parseable DOB, the wizard pauses and asks you to acknowledge degraded mode (NPI‑only‑strength screening) before continuing. Fixing DOB coverage at the source is almost always worth it.

Step 3 shows the validation summary: row count, per‑field coverage, and what each gap means for match strength. Select **Confirm mapping - run first screening →** to save the mapping. You're ready to screen.

## 5. Run your first screen (Screen & run)

Open **Screen & run**. Above the run button you'll see the freshness tiles: the exact vintage of the OIG exclusion list and the other sources this screen will use. Select **Run screening**.

The run takes seconds to a few minutes depending on roster size. When it finishes you'll see rows screened and hits graded by strength:

| Match strength | Meaning                                                            |
| -------------- | ------------------------------------------------------------------ |
| **Strong**     | Exact NPI match against an exclusion record                        |
| **Likely**     | Same name and date of birth                                        |
| **Possible**   | Advisory: same name and state, with no date‑of‑birth corroboration |

{% hint style="info" %}
**On the trial, screening is capped at the first 1,000 providers.** A larger roster is only partially screened: the rows beyond the cap are reported as not screened until you upgrade.
{% endhint %}

Every screen also checks your NPIs against deactivations, PECOS enrollment presence, opt‑outs, and upcoming revalidation deadlines; those land on the **Roster health** page.

## 6. Confirm it worked

You don't need SQL to verify a screen ran. On **Settings & export**, the **run log** shows every screen with its date, type (manual or scheduled), rows screened, status, and the exact source vintages it used. A row with your screen's timestamp and pinned vintages means your install, connection, and mapping are all working.

From here: work any hits in the **Review queue** (each disposition requires a note and becomes a permanent audit record), check **Roster health** for deactivations, PECOS gaps, opt‑outs, and revalidation deadlines, and export your CSV audit log or HTML evidence pack from **Settings & export**.

## Troubleshooting

**A freshness tile shows AGING (or the run button is blocked).** AGING means a source is past its expected refresh window but still within the screening threshold: you can run, and the exact vintage is pinned to the run record. A blocked run button means the exclusion list itself has gone materially stale; you can tick **Run against stale LEIE - record acknowledgment** to run immediately (the stale vintage is pinned to that run), or wait for the block to clear when the source refreshes. Either way, the vintage stamped on the run record is what you cite for the monthly attestation.

### "Run screening" is greyed out

**Cause:** the column mapping hasn't been confirmed yet; a connected roster can't be screened until the mapping is saved.

**Solution:**

1. Go back to **Roster setup** and complete the wizard through **Confirm mapping - run first screening →**.
2. Return to **Screen & run**; the **Run screening** button enables once the mapping is confirmed.

### The table picker doesn't show my roster table

**Cause:** the role you're using in Snowsight lacks SELECT on the table, or you don't hold the app's **app\_admin** role.

**Solution:**

1. Switch to a role with SELECT on the roster table.
2. Confirm **app\_admin** was granted to that role (step 2).
3. Re‑open **Connect your roster**; the table picker lists only objects your current role can see.

### The wizard pauses with a "degraded mode" warning

**Cause:** fewer than 80% of your roster rows have a parseable date of birth, so the Likely (name + DOB) matches can't run.

**Solution:**

1. Check the DOB column's format in your source table (mixed formats are the usual culprit).
2. Fix coverage at the source and re‑run validation; it's almost always worth it.
3. Or acknowledge degraded mode to continue with NPI‑only‑strength screening.

### My first screen returns zero hits

**Cause:** usually a healthy roster; most screens of a clean roster return few or no exclusion hits. If you expected demo hits, the demo roster may not be the connected roster.

**Solution:**

1. Confirm which roster is connected on the Roster setup page.
2. Use the built‑in demo roster; it contains 10 planted matches (2 Strong, 4 Likely, 4 Possible).
3. Check **Roster health**: deactivations, PECOS gaps, opt‑outs, and revalidation deadlines surface there, not in the review queue.

### Enabling the monthly schedule asks for new privileges

**Cause:** this is expected; the schedule runs automatically in your account on your chosen day, which needs a scheduling privilege you grant.

**Solution:**

1. Grant the privileges in the Snowsight dialog (they're opt‑in and scoped to the app).
2. Or keep screening on‑demand; manual screens never need account‑level privileges.

## Next steps

* Work hits and dispositions screen‑by‑screen: [Using the App](/data-catalog/rosterguard-app/using-the-app.md)
* Understand the confidence levels and the measured recall behind them: [Understanding Matches](/data-catalog/rosterguard-app/methodology.md)
* See exactly what RosterGuard screens against: [What It Checks](/data-catalog/rosterguard-app/data-dictionary.md)

***

**RosterGuard docs:** [Overview](/data-catalog/rosterguard-app.md) · [Using the App](/data-catalog/rosterguard-app/using-the-app.md) · [Understanding Matches](/data-catalog/rosterguard-app/methodology.md) · [What It Checks](/data-catalog/rosterguard-app/data-dictionary.md) · [Security & Plans](/data-catalog/rosterguard-app/security-and-plans.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.dataplex-consulting.com/data-catalog/rosterguard-app/quickstart.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.