The Credential Policy Manager lets you define which licenses or credentials specific groups in your organization must hold, then automatically tracks and manages the resolution process when someone falls out of compliance.

Keeping every license and credential your firm requires up to date for every person who needs one can be a manual, reactive process. Someone has to know who's required to hold what, notice when a person falls out of compliance, follow up with them, and track that follow-up through to resolution. The Credential Policy Manager automates that entire cycle.

At a high level, this feature allows you to:

• Define who needs to hold what. Specify the exact population of professionals required to carry (maintain) a given license or credential, whether that's tied to their role, service line, or their principal place of business.

• Automatically detect non-compliance. The moment someone in that population is missing a required credential, or their credential expires, the system opens a License Compliance Incident; a single record that tracks that individual’s specific compliance gap from detection through resolution.

• Route resolution without manual chasing. The affected person is notified automatically and guided toward submitting what's needed; admins get a dedicated place to review, approve, deny, or exempt the request, and no one has to remember to follow up.

• See it all in reporting. Every incident, every notification sent, and every outcome is tracked and reportable, giving you a clear audit trail of who was out of compliance, when, and how it was resolved.

In short, the Credential Policy Manager turns "who's missing a required credential" from a question your firm has to go looking for, into something the system surfaces automatically, and then helps get resolved.

Before the Credential Policy Manager can start opening and tracking incidents, a few things need to be configured. Most firms will only need a subset of this, depending on whether you're tracking credential-based requirements, location-based requirements, or both.

The Credential Policy Manager is available to Plus customers. This feature must be enabled by the LCvista Team before any of the configuration below becomes available.

Every incident is resolved through an approval request, so this needs to be right before anything else. Go to Site Settings > Approval Workflows and confirm the Jurisdiction Approval workflow reflects how you want these requests handled. For example, whether a specific license or credential requires admin approval and whether supporting documents are required.

The Credential Policy Manager supports two kinds of requirement rules, and you can use either or both in parallel:

• A Credential Requirement: a rule that says a person must hold at least one from a specific list of jurisdictions/licenses.

• A Work Location Requirement: a rule that says a person must hold whatever license corresponds to wherever they practice, based on a person field you designate (for example, a "Work Location State" custom field). The system will suggest a mapping from each location value to the jurisdiction that satisfies it, with the ability for the firm to modify before saving; this will ensure that as people move between offices or states, their requirement automatically follows them.

If you plan to write a rule like "must hold an active CPA license in any of these 50+ states," or if you are often searching for a bundle of jurisdictions, then consider defining a Credential Set (for example, "US CPA License"). Doing so will group the relevant jurisdictions together. This saves you from manually selecting every jurisdiction each time you build a rule, and the same Credential Set can be reused later for filtering notifications and reports.

• Go to the Work Location Mapping settings found within Site Settings and License Compliance Settings.

• Choose one or more existing custom person fields as source fields (the fields whose values represent "where this person works"). As an example, "Work Location State," and optionally "Previous Work Location State" for people transitioning between locations.

• Once source fields are selected, the system lists every distinct value currently found in those fields across your people, along with how many people currently have that value, so you can map each one to the jurisdiction it should require. Unmapped values are visually flagged so nothing slips through.

• Any location value you leave unmapped simply doesn't generate a requirement; it isn't treated as an error.

  

  

Decide which notifications you want active for this workflow (see Notifications & Reporting for the full list) so affected people and admins are actually alerted once incidents start being created.

Create (or identify) the dynamic groups that represent the populations you need to track. For example, "All CPA-licensed staff" or "Partners in Service Line Tax" where custom profile fields like Service Line or Rank are used to define this segmentation. On the group's rules page, within the License Compliance Rules tab, attach one or both of the following:

• A Credential Requirement rule (standard OR logic across a jurisdiction list or Credential Set), or

• A Work Location Requirement rule, which automatically applies the mappings configured in Work Location Mappings to that group's members.

A group can have more than one rule attached. For example, one Work Location rule and one Credential rule, and each is tracked as an independent compliance status for the member.

Once these steps are in place, the Credential Policy Manager is ready to run. Advanced Capabilities to Extend Your Setup covers optional enhancements: custom approval request fields, dashboard widgets, and managed-user permissions that you can layer on once the foundational features are in place.

A License Compliance Incident is the record that tracks one person's specific compliance gap, from the moment it's detected to the moment it's resolved. Here's how it moves through the system, and what each audience sees along the way.

Whenever a person's relevant data changes (group membership, a custom field value, or a credential (jurisdiction) being added, modified, or expiring) the system re-evaluates that person against every rule assigned to their groups. If they don't meet a rule, an incident opens in a Pending Resolution status, linked to the specific rule and group that triggered it.

• The affected person receives an initial non-compliance notification letting them know they're out of compliance and why.

• They can see the open incident on their own My Incidents tab, showing what's required, what's missing or expired, and its current status.

• From the incident, they take action: for a missing or expired credential, they submit a jurisdiction add/modify request, which creates an approval request tied back to the incident, and the incident status moves to Resolution in Progress.

• If a rule requires multiple credentials (for example, two mapped work locations), the incident stays open until all required credentials are satisfied; resolving one doesn't close it on its own.

• If a submission is denied by an admin, the incident reverts to Pending Resolution so the person can try again.

• Managers with the appropriate permission (more on this here) can view, and in some cases act on, incidents belonging to the people they manage.

• Admins see all open incidents in an incident list, filterable by status, rule type, and group, and searchable by person, with each incident's age visible for prioritization.

• An incident's detail view shows the rule that was violated, the specific compliance details (what's missing/expired), any linked approval request(s), and a full resolution timeline (opened, notified, submitted, status changes, assignment history).

• From the standard Approval Requests menu, admins can approve, deny, or return a submission for revision, same as any other approval request. A denial automatically reopens the associated incident.

• Admins can also grant an exemption directly from an incident, resolving it without requiring the person to obtain the credential.

• Approval requests tied to compliance incidents are visually distinguished in the Approvals table, and can be filtered separately using a "Show only license compliance incidents" filter, with a quick link back and forth between the incident list and the approval request list.

• Where enabled, admins can assign a specific team member to review an incident's approval request; that assignment is visible on the approvals table and reportable.

Resolution paths

An incident can close for more than one reason, and the specific reason is tracked for reporting:

Reminders along the way

While an incident (and its linked approval request) is open, reminder notifications can go out to both the person and admins; see more below in Notifications & Reporting.

Notifications & Reporting

Once the basics are configured, these are the tools you'll use day-to-day to stay on top of open incidents.

Notifications

All of the following are configurable, choose which to activate and customize timing where noted.

Reporting

• People report: reviews custom field information on a person's profile, including any license compliance rule and their current status.

• License Compliance report: returns one row per user/jurisdiction relationship, with the standard ability to segment by custom fields and jurisdiction fields. This report focuses on the information that lives on the jurisdiction level and is not specific to a CPE requirement.

• Approval Requests report: all approval requests, segmentable by status, who submitted, who reviewed, when, and assignment.

• Notification Log report: tracks every notification the system has triggered, useful for reconstructing the full timeline of a specific incident (when someone became non-compliant, when they responded, when it was approved).

• License Compliance Incidents report: a purpose-built, incident-level report that reports directly off incidents rather than approval requests. It includes: date the incident opened, non-compliant type, days non-compliant, the group/rule that generated it, admin notes, date/content of the last employee response, number of follow-ups, who it's assigned to and when, any approval-request custom field values, a count of open resolution requests (for incidents with more than one in flight), the jurisdictions still outstanding, the resolution reason, and exemption status. Filterable by group, date range, days non-compliant, assigned-to, status, and rule.

Advanced Capabilities to Extend Your Setup

Once the basics are running, these optional capabilities add more control and visibility:

Dashboard Widgets. End users can see an "Open Incidents of Non-Compliance" widget summarizing their own unresolved incidents, and (where configured) an "Upcoming License Expirations" widget. Managers with the appropriate permission see a parallel widget summarizing unresolved incidents across the people they manage. These are useful for surfacing open items proactively, rather than requiring someone to go looking for them.

Managed-User Permissions. Four distinct roles govern what a manager or delegate can see and do for the people they manage: