This is the full developer documentation for Unifuse # Unifuse documentation > How to set up, administer and use Unifuse, the AI-assisted student-success and enrollment platform for colleges and universities. Unifuse helps colleges and universities keep students on track and move applicants through the funnel, with an assistant that answers from the institution’s own sources and acts only with the right person’s approval. This site describes the production product: what you see at your institution’s Unifuse address today. [Signing in](/getting-started/signing-in/)Single sign-on through your institution, the first sign-in, and what the messages mean. [Advisor Brief](/student-success/advisor-brief/)Who needs attention this week, why, and one recommended action each. [Administration](/administration/overview/)Identity, roles, sessions, data and contact policy, in one place. [Integrations](/integrations/overview/)Connect your SIS, LMS, CRM, documents and channels. ## By area [Section titled “By area”](#by-area) Getting started [Signing in](/getting-started/signing-in/) · [Roles and what they can see](/getting-started/roles/) · [Your account](/getting-started/your-account/) Student Success [Success Center](/student-success/success-center/) · [Advisor Brief](/student-success/advisor-brief/) · [My Students](/student-success/my-students/) · [The student record](/student-success/student-record/) · [Risk cohorts](/student-success/risk-cohorts/) · [Messaging students](/student-success/messaging-students/) · [Review Queue](/student-success/review-queue/) · [Appointments](/student-success/appointments/) Enrollment [Enrollment Overview](/enrollment/overview/) · [Applicant CRM](/enrollment/applicant-crm/) · [Campaigns](/enrollment/campaigns/) · [Surveys](/enrollment/surveys/) · [Knowledge base](/enrollment/knowledge-base/) · [Document Analysis](/enrollment/document-analysis/) · [Conversation Intelligence](/enrollment/conversation-intelligence/) AI assistant [The AI Front Door](/ai-assistant/front-door/) · [Approvals and trust tiers](/ai-assistant/approvals/) Administration [Overview](/administration/overview/) · [Single sign-on](/administration/single-sign-on/) · [Sign-in policy](/administration/sign-in-policy/) · [SCIM provisioning](/administration/scim-provisioning/) · [Roles](/administration/roles/) · [Users](/administration/users/) · [Session policy](/administration/session-policy/) · [Contact policy](/administration/contact-policy/) · [Data policy](/administration/data-policy/) · [Privacy requests](/administration/privacy-requests/) · [Audit log](/administration/audit-log/) Integrations [Overview](/integrations/overview/) · [Connector catalogue](/integrations/connectors/) · [SIS and LMS data](/integrations/sis-and-lms-data/) · [Workspace](/integrations/workspace/) · [Channels and web chat](/integrations/channels/) Trust [Security overview](/trust/security/) · [Data handling](/trust/data-handling/) · [Accessibility](/trust/accessibility/) · [Status and updates](/trust/status-and-updates/) Reading this with an AI assistant? Every page is also at its address plus `.md`, and the whole site is indexed at [/llms.txt](/llms.txt). # Audit log > Read, filter, search and export your institution's Unifuse audit log, which records sign-ins, administration changes, data access and assistant actions and is never purged. **Audit Logs** in the sidebar opens the institution’s governance ledger: an append-only record of security events, administration changes, data access and AI actions. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *view audit* permission. Only Admin holds it by default. * Exporting also needs *export data*. ## Summary tiles [Section titled “Summary tiles”](#summary-tiles) * **Total Events (24h)** * **Security Flags**, which filters the list when selected * **Admin Actions** * **Compliance Score**, a heuristic: the share of recent events that are not Critical ## Filter and search [Section titled “Filter and search”](#filter-and-search) * Quick filters: **All**, **Critical**, **Security**. * The **Filter** popover: **Date range** (last 7, 30 or 90 days, all time, or custom; default 30 days), **Log type** (Security, AI, Data, Admin) and **Severity** (Info, Warning, Critical). * **Search** matches the action, target, user and details. Select a row to open its detail panel; **Copy JSON** copies the full record. ## Export [Section titled “Export”](#export) **Export CSV** produces a file honouring the current filters, up to 50,000 rows. ## What is recorded [Section titled “What is recorded”](#what-is-recorded) Among other events: every sign-in and failed sign-in; session timeouts and sign-outs; role and permission changes; SCIM provisioning; changes to the sign-in, session, data and contact policies; sends and overrides of the contact policy; unmasking of personal data; erasure requests; and assistant actions and their approvals. The audit log is never purged and is not affected by the retention windows in [Data policy](/administration/data-policy/). # Contact policy > Set the rules every student-facing message from Unifuse must pass: message budgets, quiet hours, channel order, whether the assistant replies automatically, staff overrides and opt-outs. Every message Unifuse sends to a student, whether from a campaign, an advisor or the assistant, passes through the institution’s contact policy. The **Contact policy** tab is where that policy is set. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage institution* permission. The opt-out section also needs *manage campaigns*. * Open **Administration → Contact policy**. ## Budget [Section titled “Budget”](#budget) | Setting | Range | Default | | --------------------------- | ------------------------------ | ------- | | **Messages per window** | 1 to 20 | 1 | | **Window (days)** | 1 to 90 | 7 | | **Minimum spacing (hours)** | 0 to 2160; 0 turns spacing off | 24 | The budget is per student, rolling, and counted across all channels. ## Quiet hours [Section titled “Quiet hours”](#quiet-hours) **From** and **Until** are 24-hour times in the chosen **Time zone** (a list of common zones, or **Other** to type an IANA zone name). The default is 21:00 to 08:00 in America/New_York. Setting the same time for both turns quiet hours off. Quiet hours block proactive and transactional sends. A reply to a student who has just written in is exempt. ## Channel preference [Section titled “Channel preference”](#channel-preference) An ordered list of channels, from SMS, Email, WhatsApp, Web chat and Voice. At least one is required. The default is SMS then Email. ## Assistant replies [Section titled “Assistant replies”](#assistant-replies) **Reply mode** is **Calibration** (recommended, the default) or **Auto**. In Calibration, the assistant’s replies to students wait in the Review Queue for a person to approve. In Auto they are sent directly, still subject to the budget and quiet hours. ## Overrides [Section titled “Overrides”](#overrides) **Allow staff to send past the budget and quiet hours** is on by default. When a member of staff overrides, they must give a reason, and the override is logged. ## Saving [Section titled “Saving”](#saving) A **Preview** sentence reads the form back as a rule. **Save contact policy** applies it; **Discard changes** reverts. Every change is recorded in the audit log with the values before and after. ## Opt-outs [Section titled “Opt-outs”](#opt-outs) The consent section lists people who have opted out of contact, filtered by **Opted out**, **Opted in** or **All**. * **Record an opt-out on someone’s behalf**: choose the **Channel**, enter the **Phone number or email**, and optionally a **Reason**. * **Restore** lifts an opt-out. An opt-out can never be overridden by the budget, by staff or by the assistant. ## Related [Section titled “Related”](#related) * [Student Success: Review Queue](/student-success/review-queue/) # Data policy > Choose how Unifuse redacts personal data and how long it keeps conversations and drafts before nightly purges remove them. The **Data policy** tab holds the institution’s redaction mode and retention windows. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage institution* permission. * Open **Administration → Data policy**. ## Personal-data redaction [Section titled “Personal-data redaction”](#personal-data-redaction) **PII redaction** is **Full** (recommended and the default), **Partial** or **Off**. It controls how personal data is masked in conversation records and in what is shown to the assistant. ## Retention windows [Section titled “Retention windows”](#retention-windows) | Data | Range (days) | Default | | ------------------------- | ------------ | ------- | | Conversations | 30 to 3650 | 365 | | Abandoned campaign drafts | 7 to 365 | 30 | | Advisor Brief drafts | 7 to 365 | 30 | Purges run nightly. Data past its window is deleted and cannot be recovered. ## What retention does not cover [Section titled “What retention does not cover”](#what-retention-does-not-cover) The audit log is append-only and is never purged. Student and applicant records come from your institution’s systems and are removed by erasure requests, by disconnecting a source, or when the institution leaves Unifuse. See [Privacy requests](/administration/privacy-requests/) and [Trust: data handling](/trust/data-handling/). # Administration overview > Where the Administration page is in Unifuse, what each tab does, and which permission each tab needs. **Administration** is where an institution’s Unifuse owners manage identity, access, sessions, data handling and student-contact rules. It is in the sidebar for anyone who holds at least one administration permission, and also reachable from **Settings → Team & Roles**. Each tab is shown only to people with the permission it needs. The Admin role holds all of them. | Tab | What it is for | Permission | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | | [Single Sign-On](/administration/single-sign-on/) | Connect the institution’s identity provider (OIDC or SAML). | manage institution | | [Sign-in policy](/administration/sign-in-policy/) | Which email domains may sign in, and whether to link existing accounts by email. | manage institution | | [SCIM Provisioning](/administration/scim-provisioning/) | Issue and revoke tokens so the identity provider can create, update and deactivate users. | manage SCIM | | [Roles](/administration/roles/) | The permission matrix; create and delete roles. | manage roles | | [Users](/administration/users/) | Assign roles and sign people out. | manage users | | [Sessions](/administration/session-policy/) | Idle timeout and maximum session length. | manage institution | | Workspace | Connect Google Workspace or Microsoft 365 for document and calendar access. This is not sign-in. See [Workspace](/integrations/workspace/). | manage connectors | | Channels | SMS numbers and web-chat deployments. See [Channels](/integrations/channels/). | manage channels | | [Privacy requests](/administration/privacy-requests/) | Erasure requests from people whose data the institution holds. | manage privacy requests | | [Data policy](/administration/data-policy/) | Personal-data redaction mode and retention windows. | manage institution | | [Contact policy](/administration/contact-policy/) | Message budgets, quiet hours, channel order, assistant reply mode and opt-outs. | manage institution | | Modules | Turn optional areas on or off: the **Career hub** and **Voice input**, both off by default. Voice input tells users that their browser vendor transcribes the audio. | manage institution | Every change made on these tabs is written to the [audit log](/administration/audit-log/). ## Related [Section titled “Related”](#related) * [Roles and what they can see](/getting-started/roles/) # Privacy requests > Handle requests to erase a person's data from Unifuse: how requests arrive, the dry run, what is erased and what is kept, and what your institution must do in its own systems. The **Privacy requests** tab is where an institution reviews and carries out erasure requests from people whose data Unifuse holds. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage privacy requests* permission. * Open **Administration → Privacy requests**. ## How requests arrive [Section titled “How requests arrive”](#how-requests-arrive) * A user chooses **Request erasure** on their own profile. See [Your account](/getting-started/your-account/#my-profile). * An administrator logs a request received by other means with **Log a request received outside the app**, giving the **Subject’s email** and, optionally, a **Phone**, which is used only to find text messages. Each request gets a reference beginning `ER-` and a due date 30 days after it was received. Administrators are emailed when a request arrives (this email cannot be muted), and the bell in the header shows open requests. ## The list [Section titled “The list”](#the-list) Columns are Reference, Subject, Received, Due and Status. Overdue requests are marked. **Review** opens an open request; **View** opens a closed one. ## Review and erase [Section titled “Review and erase”](#review-and-erase) 1. Select **Review**. Unifuse runs a dry run and shows what would be erased: a count of rows by table, a section headed **What is kept, and why**, and any uploaded documents matched by the person’s name. Each document has a toggle so you can include or exclude it. 2. To proceed, select **Erase** and type the subject’s email address back to confirm. The erasure runs as a single operation and cannot be undone. 3. To refuse, select **Decline** and give a reason. ## What is erased and what is kept [Section titled “What is erased and what is kept”](#what-is-erased-and-what-is-kept) * The person’s student and applicant records, messages and conversation history are deleted. * A Unifuse user account is scrubbed of personal data and deactivated rather than deleted, so the audit trail of what that account did stays intact. * Opt-outs are kept as a suppression record, so the person is not contacted again. * The audit log is never altered. ## In your own systems [Section titled “In your own systems”](#in-your-own-systems) Unifuse holds a copy of data from your student information system and your identity provider. Remove the person there too; otherwise the next sync or sign-in re-creates their records. ## Related [Section titled “Related”](#related) * [Data policy](/administration/data-policy/) * [Trust: data handling](/trust/data-handling/) # Roles > Edit the permission matrix for your institution's Unifuse roles, create roles from scratch or by copying, and understand the rules that protect you from locking yourself out. The **Roles** tab is a matrix of permissions against roles. It is where you decide what each kind of user at your institution can see and do. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage roles* permission. * Open **Administration → Roles**. * Read [Roles and what they can see](/getting-started/roles/) for the stock roles. ## Read the matrix [Section titled “Read the matrix”](#read-the-matrix) Rows are permissions, grouped by product area, each with a short description. Columns are roles; each header shows how many permissions and how many users the role has, and marks the institution’s default role. ## Grant or remove a permission [Section titled “Grant or remove a permission”](#grant-or-remove-a-permission) Select a cell to grant the permission to that role, or select it again to remove it. The change applies on the next request for everyone with the role; nobody needs to sign in again. ## Create a role [Section titled “Create a role”](#create-a-role) 1. Select **Create role** and enter a **Role name**. Names must be unique. 2. Choose **Start empty** or **Copy from** an existing role. 3. Grant permissions in the matrix. ## Delete a role [Section titled “Delete a role”](#delete-a-role) **Delete** is offered only on a role that is not the default role, is not the Admin role, and has no users. Move users to another role first. ## Rules [Section titled “Rules”](#rules) * The Admin role holds every permission and cannot be edited. * You cannot edit the permissions of the role you hold yourself. * You cannot grant a permission that you do not hold. * Changing which role is the default for new users is not available on this screen. Ask Unifuse support. ## Related [Section titled “Related”](#related) * [Users](/administration/users/) # SCIM provisioning > Let your identity provider create, update and deactivate Unifuse users automatically over SCIM 2.0, including the base URL, token issuance, supported attributes and limits. With SCIM provisioning, your identity provider (Okta, Microsoft Entra ID or any SCIM 2.0 client) keeps Unifuse users in step with your directory: joiners are created, name changes flow through, and leavers are deactivated and signed out. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage SCIM* permission. * Open **Administration → SCIM Provisioning**. ## Issue a token [Section titled “Issue a token”](#issue-a-token) 1. Enter a **Description** that identifies the client, such as “Okta production”. 2. Optionally enter **Allowed CIDRs**, comma-separated, to accept the token only from your identity provider’s egress addresses. Requests from other addresses are refused. 3. Select **Generate token**. 4. Copy the token now. It is shown once and cannot be retrieved later. The list shows each token’s description and its IP restriction, with **Revoke**. Revoking takes effect immediately. ## Configure the identity provider [Section titled “Configure the identity provider”](#configure-the-identity-provider) | Setting | Value | | ------------------- | ------------------------------------------------------------- | | SCIM base URL | Your institution’s Unifuse address followed by `/api/scim/v2` | | Authentication | Bearer token (the token issued above) | | Supported resources | Users only. Groups are not supported. | Unifuse publishes `/ServiceProviderConfig` and `/ResourceTypes` under the base URL for clients that read them. ## Supported attributes [Section titled “Supported attributes”](#supported-attributes) | SCIM attribute | Unifuse field | | ----------------------------------- | ------------------------------------------ | | `userName` | Email address (stored lower-case) | | `name.givenName`, `name.familyName` | Display name | | `externalId` | Single sign-on subject | | `active` | Whether the account is active | | Enterprise extension `department` | Department (set on create and full update) | ## What SCIM does and does not do [Section titled “What SCIM does and does not do”](#what-scim-does-and-does-not-do) * A new user gets the institution’s default role. SCIM never assigns roles; use [Users](/administration/users/) or an identity-provider [role map](/administration/single-sign-on/#mapping-roles). * Setting `active` to false, or deleting the user, deactivates the account and ends all of its sessions immediately. * Creating a user whose email belongs to a deactivated account reactivates that account. * Partial updates (`PATCH`) support `replace` operations in both the Okta and Entra ID styles. * Filters support `userName eq`, `externalId eq` and the Entra ID `emails[type eq "work"].value eq` form. Listings return at most 500 users. Sorting, bulk operations and entity tags are not supported. * Every provisioning action is recorded in the [audit log](/administration/audit-log/). ## Related [Section titled “Related”](#related) * [Single sign-on](/administration/single-sign-on/) * [Users](/administration/users/) # Session policy > Set how long Unifuse sessions last for your institution: the idle timeout and the maximum session length, what counts as activity, and how timeouts are recorded. The **Sessions** tab sets two limits that end a user’s session automatically. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage institution* permission. * Open **Administration → Sessions**. ## Settings [Section titled “Settings”](#settings) | Setting | Range | Default | | ---------------------------------- | ----------------------------------------------------------------------- | -------------------- | | **Idle timeout (minutes)** | 5 up to the platform ceiling | 60 | | **Maximum session length (hours)** | 1 up to the platform ceiling, in half-hour steps, measured from sign-in | the platform ceiling | The idle timeout cannot be longer than the maximum session length. The platform ceilings are 480 minutes idle and 24 hours maximum. ## How enforcement works [Section titled “How enforcement works”](#how-enforcement-works) * Both limits are checked on every request. Tightening a limit ends any session that is already past it. * Only things the user does count as activity. Background refreshes, such as the notification bell, do not keep a session alive. * There is no warning before an idle timeout. The user is returned to the sign-in page with a message that their session ended. * Timeouts, expiries and sign-outs are recorded in the [audit log](/administration/audit-log/). ## Related [Section titled “Related”](#related) * [Users](/administration/users/) to sign a specific person out now * [Your account](/getting-started/your-account/#security) for how users manage their own sessions # Sign-in policy > Control which email domains can sign in to your Unifuse institution and whether a first-time sign-in may be linked to an existing account by email. The sign-in policy decides who at your institution may complete single sign-on, beyond what the identity provider itself allows. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage institution* permission. * Open **Administration → Sign-in policy**. ## Allowed email domains [Section titled “Allowed email domains”](#allowed-email-domains) Your institution’s own domain is always allowed. **Additional allowed email domains** takes a comma-separated list of extra domains, up to 50. Subdomains are not implied: list `law.example.edu` as well as `example.edu` if both should sign in. The read-only **Sign-in is allowed from** list shows the result. A user whose email domain is not allowed is refused at sign-in even if the identity provider accepts them. ## Link existing accounts by email [Section titled “Link existing accounts by email”](#link-existing-accounts-by-email) **Link existing accounts by email** is off by default. It matters when someone signs in for the first time from an identity that Unifuse has not seen, but whose email address already belongs to a Unifuse account (for example an account created earlier through SCIM, or after the institution changed identity providers). * **Off**: the sign-in is refused, so an identity cannot take over an existing account by sharing its email address. * **On**: the identity is linked to the existing account and the link is recorded in the audit log. Turn it on during an identity-provider migration, then turn it off again. ## Notes [Section titled “Notes”](#notes) * Changes apply from the next sign-in. * OIDC sign-ins require the identity provider to report the email address as verified. # Single sign-on > Connect your institution's identity provider to Unifuse over OIDC or SAML, map identity-provider attributes to Unifuse roles, and what to configure on the identity-provider side. Unifuse signs users in only through the institution’s identity provider. This page covers connecting that provider. Any provider that speaks OpenID Connect (OIDC) or SAML 2.0 works, including Google Workspace, Microsoft Entra ID, Okta and Shibboleth. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage institution* permission (Admin by default). * In your identity provider, you need to be able to register an application and read its details. * Open **Administration → Single Sign-On**. ## What to register in your identity provider [Section titled “What to register in your identity provider”](#what-to-register-in-your-identity-provider) Register Unifuse as an application using your institution’s Unifuse address (the address your users sign in at) as the base. Values below are relative to that address. **OIDC** * Redirect (callback) URI: `/api/auth/sso/oidc/callback` * Grant type: authorization code. Unifuse asks for the standard profile and email scopes and requires a verified email address. **SAML** * Service-provider metadata: `/api/auth/sso/saml/metadata`. Most providers can import this directly. * Assertion consumer service (callback) URL: `/api/auth/sso/saml/callback` * Release at least an email address and a display name. Unifuse reads the common attribute names and their OIDs (`mail`, `displayName` or `cn`, `givenName` and `sn`, `ou` or department), so a standard attribute release usually needs no mapping. ## Add a provider [Section titled “Add a provider”](#add-a-provider) 1. Choose the **Protocol**: **OIDC** or **SAML**. 2. For OIDC, enter the **Client ID**, **Client Secret** and the **Discovery URL** (the provider’s `.well-known/openid-configuration` address). 3. For SAML, enter the **IdP Entity ID**, **IdP SSO URL** and the **IdP X.509 certificate** in PEM form. 4. Optionally set a **Role source attribute** (for example `eduPersonAffiliation`) and a **Role map JSON** such as `{"faculty": "Advisor", "staff": "Viewer"}`. See [Mapping roles](#mapping-roles). 5. Select **Add provider**. The list below the form shows each provider’s protocol, whether it is active, its discovery URL or entity ID, and its role map. **Remove** deletes a provider. Caution Sign-in uses the first active provider. Keep one provider active per institution. To change providers, add the new one, test it, then remove the old one. ## Mapping roles [Section titled “Mapping roles”](#mapping-roles) If a role source attribute and role map are set, a user’s role is taken from the map the first time they sign in. Values that are not in the map, or users without the attribute, get the institution’s default role. The mapping only applies when the user has no role yet. Roles that administrators set by hand in [Users](/administration/users/) are never overwritten by a later sign-in. ## Testing [Section titled “Testing”](#testing) Sign in from a private browser window with an account at your institution. If sign-in fails, the reason is recorded in the [audit log](/administration/audit-log/) as a *Login Failed* event, and the sign-in page shows a message explained in [Signing in](/getting-started/signing-in/#sign-in-messages). ## Related [Section titled “Related”](#related) * [Sign-in policy](/administration/sign-in-policy/) for allowed email domains * [SCIM provisioning](/administration/scim-provisioning/) to create and deactivate users from the identity provider # Users > Assign roles to your institution's Unifuse users, see who is active, and sign someone out of every session. The **Users** tab lists everyone at your institution with a Unifuse account. ## Before you start [Section titled “Before you start”](#before-you-start) * You need the *manage users* permission. * Open **Administration → Users**. ## Columns [Section titled “Columns”](#columns) | Column | Meaning | | -------- | ------------------------------------------------------------- | | User | Name and email, as provided by the identity provider or SCIM. | | Role | A drop-down of the institution’s roles, plus *(no role)*. | | Active | Whether the account can sign in. Read-only here. | | Sessions | **Sign out** (not shown on your own row). | ## Assign a role [Section titled “Assign a role”](#assign-a-role) Choose a role in the **Role** drop-down. The change applies immediately and is recorded in the audit log. You cannot change your own role, and you cannot assign a role that holds permissions you do not have yourself. ## Sign someone out [Section titled “Sign someone out”](#sign-someone-out) **Sign out** opens a confirmation showing how many sessions the person has. **Sign out everywhere** ends all of them. The person can sign in again straight away unless their account has been deactivated, so to remove access, deactivate them at the identity provider or through SCIM as well. ## Adding and removing people [Section titled “Adding and removing people”](#adding-and-removing-people) There is no invite or deactivate button. Accounts are created the first time a person signs in through single sign-on, or by SCIM provisioning. Accounts are deactivated by SCIM, which also ends their sessions. See [SCIM provisioning](/administration/scim-provisioning/). ## Related [Section titled “Related”](#related) * [Roles](/administration/roles/) * [Session policy](/administration/session-policy/) # Approvals and trust tiers > How Unifuse decides who must approve an action the AI assistant proposes, what the approval cards show, and what the assistant is never allowed to do. Every action the assistant takes through a tool is recorded in the audit log. The tool’s trust tier decides who has to say yes before it runs. ## The tiers [Section titled “The tiers”](#the-tiers) | Tier | Who decides | What you see | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | **Tier 1, autonomous** | Nobody; the call is logged. | The result. Read-only tools such as knowledge-base search, student lookups, summaries and metrics. | | **Tier 2, requester confirms** | The person who asked. | A card in the chat: the tool it wants to run and its exact parameters, with **Confirm** and **Don’t run**. The request expires after 24 hours. | | **Tier 3, staff approval** | A holder of *approve agent actions* other than the requester (Advisor by default). | “Sent to staff reviewers for approval” with a link to the Approvals page. Expires after 72 hours. | | **Tier 4, administrator approval** | A holder of *approve escalated agent actions* other than the requester (Admin by default); approvers are emailed. | “Sent to an administrator for approval”. Expires after 72 hours. | A tier 2 request from someone who does not hold the tool’s own permission is raised to tier 3. Sending a nudge to a student is tier 2 and cannot be set lower. ## What the assistant can never do [Section titled “What the assistant can never do”](#what-the-assistant-can-never-do) Some actions are not available to the assistant at any tier: deleting records, changing permissions or trust tiers, the kill switch, exports, bulk or campaign sends, holds, and anything to do with financial aid or billing. People do those. ## The Approvals page [Section titled “The Approvals page”](#the-approvals-page) **Approvals** appears in the sidebar for people who can approve. It has two sections: **Needs your confirmation** (your own tier 2 requests) and **Review queue**. The page checks for new requests every 30 seconds. Each card shows the tool and its tier, where the request came from (web chat, a channel or an automation), who requested it and when, when it expires, the decision basis, and **Exact parameters that will execute**, verbatim. Add an optional **Decision note**, then **Approve** or **Deny**. Both are recorded in the audit log with the note. Administrators also see an **Oversight review** tab for rating past decisions on scope accuracy, utility and veracity. ## The kill switch [Section titled “The kill switch”](#the-kill-switch) An administrator can pause every agent at the institution from the Orchestration Hub’s global configuration. While it is on, the assistant, the web chat widget and the SMS line stop responding. ## Related [Section titled “Related”](#related) * [The AI Front Door](/ai-assistant/front-door/) * [Audit log](/administration/audit-log/) # The AI Front Door > Ask the Unifuse assistant about your students, documents, applications and campaigns; how it cites sources, abstains when unsure, and asks before it acts. The AI Front Door is the assistant built into Unifuse. Open it from the chat bubble in the header or the ask bar on the Orchestration Hub. It answers from your institution’s knowledge base and the Expert Nodes configured for your institution, and it says when it does not know. ## What it knows [Section titled “What it knows”](#what-it-knows) The left panel, **What this front door knows**, lists the live knowledge-base sources and the Expert Nodes that are online. The assistant only answers from those; it does not guess. Student questions return only students in your scope. Suggested starting points include “How many students are at risk this week?”, “Show me pending document reviews”, “Where do this cycle’s applications come from, by state?” and “Summarize recent campaign performance”. **Start a campaign** (for roles with *manage campaigns*) runs a three-question intake that creates a real campaign draft and opens the builder. ## Reading an answer [Section titled “Reading an answer”](#reading-an-answer) An answer can include the steps the assistant took, result cards (a student you can open, or a chart with its source and record count), numbered citations that link to the source, a confidence percentage, and an **Abstained** badge when the assistant found nothing it could answer from. Anything that looks like code, configuration or credentials is replaced with a refusal. ## Your conversation [Section titled “Your conversation”](#your-conversation) Your thread is kept on the server per user, survives navigation and reloads, and is cleared when you sign out. **New conversation** starts afresh. If your institution has turned on the **Voice input** module, a microphone appears in the input. The transcription is done by your browser vendor. ## When the assistant wants to act [Section titled “When the assistant wants to act”](#when-the-assistant-wants-to-act) Some requests ask the assistant to do something, such as send a nudge to a student. Those actions are governed by trust tiers: the assistant shows what it wants to run and does not run it until the right person says yes. See [Approvals and trust tiers](/ai-assistant/approvals/). ## Related [Section titled “Related”](#related) * [Knowledge base answers](/enrollment/knowledge-base/) # AI Concierge > Run campus tours, admissions events and orientation in Unifuse: create events, import or add registrants, keep an itinerary, track check-ins and report on attendance. **Enrollment → AI Concierge** manages daily tours, admissions events and orientation sessions and the people registered for them. Your CRM stays the system of record; import its list here. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view events* to see events and *manage events* to create or change them. ## Create an event [Section titled “Create an event”](#create-an-event) 1. Select **New event**. 2. Enter the **Event name**, choose the **Kind** (Daily tour, Admissions event or Orientation), set the **Date**, **Starts** and **Ends** times, the **Location** and a **Description**. 3. Select **Create event**. ## The events list [Section titled “The events list”](#the-events-list) The hero shows what is happening now or next, with **Open event**. Cards count upcoming, live, registrants and completed events. The table filters by All, Upcoming, Live now and Completed and shows each event’s kind, lifecycle, registrations and check-ins. ## An event [Section titled “An event”](#an-event) * Cards for Registered, Checked in, Cancelled and No-show. * **Registrants**: **Import CSV** (columns for first name, last name or name, email, phone, major, term and ID; rows already on the event are skipped and the result is reported), or add one by hand with **First name** (required), **Last name**, **Email** and **Phone**. Each registrant has a status of Registered, Checked in, Cancelled or No-show, and can be removed. * **Itinerary**: stops with a time, name and location. **Add stop**, then **Save itinerary**. * **Questions needing a person** opens the Review Queue for questions visitors asked the assistant about the event. * **Delete event**. ## Reporting [Section titled “Reporting”](#reporting) **Reporting** shows events, registrants, check-ins and no-shows overall and by event, with **Export CSV**. The export contains counts only, no personal data. ## Related [Section titled “Related”](#related) * [Review Queue](/student-success/review-queue/) # Applicant CRM > Work the applicant pipeline in Unifuse: search and filter applicants, move them through the nine stages, keep counselor notes and tags, and read the application timeline. **Enrollment → Applicant CRM** is the list of applicants synced from your CRM or admissions system, with a detail page for each. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view applicants* to read and *manage applicants* to change stages, notes and tags. * The banner shows when the data was last synced. ## The list [Section titled “The list”](#the-list) Six KPIs: Total Applicants, Submitted, Admitted, Deposits Paid, Enrolled and Avg Progress. Find applicants with **Search** (name, ID, program, email) and the filters: * **Stage**: Inquiry, Application Started, Application Submitted, Documents Review, Under Review, Decision Pending, Admitted, Deposit Paid, Enrolled. * **Status**: Active, Stalled, Admitted, Deferred, Denied, Withdrawn, Enrolled. * **Term** and **Level** (Undergraduate, Graduate). **AI Query** (needs *manage applicants*) accepts a short phrase such as “admitted international applicants” and applies the matching filters; it understands a fixed set of terms (admitted, enrolled, stalled, international, transfer, high priority, graduate, deposit, missing documents). Clear it to return to the ordinary filters. The table sorts by applicant, stage, progress, status and priority, and pages ten at a time. ## The applicant record [Section titled “The applicant record”](#the-applicant-record) The header shows status, priority and application type, with cards for progress, stage, documents and prior GPA. * **Application Progress** is a stepper. **Advance Stage** and **Revert** move the applicant (needs *manage applicants*). Reaching Admitted or Enrolled updates the status to match, and every move is added to the timeline. * **Document Checklist** shows each required document as Verified, Received, Pending or Waived. Documents are managed in your admissions system; this view is read-only. * **Application Details**, **Academic Background** and **Financial & Engagement** summarise what your systems supplied. * **Counselor Notes**: **Add Note** then **Save Note**. * **Tags**: type a tag and **Add**; remove with the cross. * **Application Timeline** lists stage changes and other events. Opening an applicant record is written to the audit log. ## Related [Section titled “Related”](#related) * [Enrollment Overview](/enrollment/overview/) # Campaigns > Plan, build, check and launch outreach campaigns in Unifuse: the six-step wizard, the server-side pre-flight checklist, recipient lists and contacts, templates, reporting and campaign details. The **Campaign** hub is where enrollment and success teams run outreach at scale by email, SMS and WhatsApp. Every launch goes through the same contact gate as a one-to-one message: consent, budget and quiet hours. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view campaigns* to look and *manage campaigns* to create and launch. Test sends need *send messages*; importing contacts into lists needs *manage recipient lists*; CSV reports need *export data*. * Email and SMS must be configured for your institution. The pre-flight checklist will tell you if a channel is not. ## Overview [Section titled “Overview”](#overview) **Campaign → Overview** shows total campaigns, total audience, average engagement and delivery rate, charts of campaigns by status and deliveries by channel, and recent campaigns. ## Campaign manager [Section titled “Campaign manager”](#campaign-manager) **Campaign → Campaign** has six tabs: | Tab | What it holds | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Intelligence | Campaign counts, audience reached, deliveries and outcomes by channel, findings from the insight feed, recent campaigns. | | Campaigns | Your campaigns, filtered by active, scheduled, paused or all, searchable, with a filter for channel and audience segment. An **Unfinished drafts** strip offers **Resume** or **Discard**. | | Templates | The template library. See [Templates](#templates). | | Recipient Lists | Lists of contacts with their source, members and the campaigns that used them. | | Users | The campaign contacts store, with **Add New User** and **Bulk Upload Users**. | | Reporting | The report builder. See [Reporting](#reporting). | ## Build a campaign [Section titled “Build a campaign”](#build-a-campaign) **New Strategy** opens the Campaign Orchestrator. Drafts save automatically as you go; if the same draft is changed elsewhere, a banner offers **Reload**. 1. **Strategy details**: **Campaign Name** (required); **Primary Goal** (yield, application completion, event registration, fundraising, retention); **Channel Mix** (Email, SMS, WhatsApp; at least one); **Key Context / Notes**. 2. **Recipients**: choose the **Target Audience** segment from the contacts store. Email and phone can be edited inline, and **Add new contact** adds one. At least one matching contact is required. 3. **Choose Creation Engine**: **AI Architect** (give instructions, **Generate Content**, refine), **Template Library**, or **Manual / 3rd Party** (paste HTML or text). 4. **Content**: write or adjust the message. Merge tags `{{FirstName}}`, `{{Name}}`, `{{Email}}` and `{{Phone}}` are filled per recipient; preview them as written or as a sample contact. 5. **Message preview**: desktop and mobile views, and for SMS a phone frame with the segment count. 6. **Review & launch**: a summary with edit links, and the **Pre-Flight Checklist**. ## The pre-flight checklist [Section titled “The pre-flight checklist”](#the-pre-flight-checklist) The checklist runs on the server and reports how many recipients are reachable, opted out, or have no address. Failures block the launch: a channel that is not configured, an empty body, an email without a subject, a missing unsubscribe link, or an audience that is empty or unreachable. Warnings do not block: unresolved merge tags, multi-part SMS, missing addresses, or high suppression. **Send test to me** sends the message to your own address only. You must tick the consent confirmation before **Launch Campaign** is available. The server runs the checklist again at launch and refuses if anything now fails. Each recipient’s send goes through the contact gate, so some may be skipped for consent, budget or quiet hours; the result reports how many succeeded, failed and were skipped. ## Recipient lists and contacts [Section titled “Recipient lists and contacts”](#recipient-lists-and-contacts) Expanding a list shows its members and **Add contacts from a file** (CSV or Excel). The import previews first, then reports rows read, added, updated, needing review, added to the list and skipped, with **Download skipped rows**. Existing contacts are not overwritten unless you **Apply updates**. Contacts who previously unsubscribed are imported as suppressed: a file cannot undo an opt-out. ## Templates [Section titled “Templates”](#templates) **Create Template** offers **Upload Pre-existing Template** (an HTML file, with an AI review) or **Create from Scratch**: name, department, tone, description, goal, owner and parameters, then look and feel (font, colours, header image), **Generate Template**, and refinement in plain language. The preview opens in Preview, Edit or Code modes, with **Export HTML**, **Send Test** to your own address, and a typed confirmation to delete. ## Reporting [Section titled “Reporting”](#reporting) Name the report, choose data points from Delivery (attempts, sent, delivered and their rates), Engagement (opened, clicked, replied and their rates) and Failures (failed, skipped or unsubscribed and their rate), filter by campaign and date range, then **Generate Report** or **Export CSV**. Engagement figures depend on the email provider reporting opens and clicks back to Unifuse. ## Campaign details [Section titled “Campaign details”](#campaign-details) Each campaign’s page shows recipients, delivery rate, sent, failed and opt-outs, a preview of the message as launched, and tabs for Analytics (delivery status and channel performance), Recipients (status, attempts and last activity per recipient) and Opt-Outs. ## Unsubscribe [Section titled “Unsubscribe”](#unsubscribe) Every launched email carries an unsubscribe link. It needs no sign-in, never expires, and records an opt-out for that address on the email channel. Anything already queued stops within a short while. Restoring an opt-out is done in [Contact policy](/administration/contact-policy/#opt-outs). ## Related [Section titled “Related”](#related) * [Messaging students](/student-success/messaging-students/) for the contact gate * [Surveys](/enrollment/surveys/) # Conversation Intelligence > Read transcripts, work the Review Queue and escalations, see which agents and skills are in use, and generate analytics across every Unifuse conversation. **Conversation Intelligence** brings together every conversation the assistant has had with prospects, applicants and students across channels. It opens from the Enrollment Overview and the Enrollment Agent page, and its tabs are kept in the page address. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view conversation logs*. Deciding on queued replies and escalations needs *manage review queue*. Seeing unmasked contact details needs *unmask pii* (Admin only by default). ## All Transcripts [Section titled “All Transcripts”](#all-transcripts) Search by participant or summary, filter by channel and by source (Channels, Student Success, Enrollment), and **Load more**. Each transcript shows which tools the agent used. Contact details are masked for roles without *unmask pii*, and a banner says so. ## Review Queue [Section titled “Review Queue”](#review-queue) Assistant replies waiting for a person, with counts of pending, held and deferred items. Nothing here has reached the student yet. See [Review Queue](/student-success/review-queue/) for how to decide. ## Conversational Agents [Section titled “Conversational Agents”](#conversational-agents) A card per agent: deployed channels, enabled skills, total conversations, average accuracy, resolution rate and active sessions. ## Skills [Section titled “Skills”](#skills) A read-only library of the skills agents can use, filtered by category and whether they are in use, with the agents that use each and its use cases. Skills are switched on in the Orchestration Hub. ## Escalations [Section titled “Escalations”](#escalations) Conversations an agent flagged for a person, in **Needs a decision**, **In review** and **Resolved**. Sort by priority or newest, and search the queue. Each row shows who, why it escalated, the recommended action, priority and source; some are marked **Auto-escalated**. The drawer shows the recommended action and the transcript, and offers **Assign to** (a name or email), **Mark in review**, **Resolve** and **Reopen**, with Previous and Next (also the left and right arrow keys). A **Handled today** strip lets you **Release** an item back to the queue. ## Conversation Insights [Section titled “Conversation Insights”](#conversation-insights) Aggregated analytics across all agents and channels. **Generate Report** writes a conversation analytics report from the figures. **Manage Cards** chooses and orders the cards: health metrics, top themes, most invoked skills, peak hours, channel usage and time-of-day distribution. ## Enrollment Agents [Section titled “Enrollment Agents”](#enrollment-agents) **Enrollment → Enrollment Agent** lists the agents that answer prospects and applicants and where they are deployed, with a search and category chips. Each agent’s page has a real **Chat with Agent** test (optionally with an applicant’s email to look up their application), a **QA Test**, and a conversations table with a transcript drawer showing sentiment, detected intents, extracted entities and whether a review is required. ## Related [Section titled “Related”](#related) * [Approvals and trust tiers](/ai-assistant/approvals/) # Document Analysis > Upload transcripts and application documents to Unifuse for extraction and an integrity check, read the results, and review documents before they are accepted. **Enrollment → Document Analysis** processes transcripts, applications and supplementary materials: it extracts the data they contain and checks their integrity. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view doc processing* to open the screen and *manage doc processing* to upload. * Documents from connected systems arrive through [Integrations](/integrations/overview/) (the **Connections** button goes there). ## Upload a document [Section titled “Upload a document”](#upload-a-document) 1. Select **Manual Upload**. 2. Drop a PDF, text, PNG or JPEG file on the dialog, or select it. 3. Select **Start processing**. When processing finishes, the dialog shows a **Processed** banner with the extraction confidence, the **Extracted data** (fields, and for transcripts a table of courses with code, title, term, grade and credits), and the **Integrity check** with a risk level, its rationale and any flags. **Upload another** or **Open in Transcripts**. ## Tabs [Section titled “Tabs”](#tabs) * **Document Dashboard**: documents processed, average extraction confidence, fraud-flagged, pending review, and a breakdown by status. * **Transcripts**: the transcript processor, with extracted data, outstanding requirements and the integrity check for each transcript. * **Application Fraud Detector**: documents whose integrity check raised flags. ## Review [Section titled “Review”](#review) Documents that need a person wait on the review queue, where a reviewer can **Approve** or **Reject** with notes. They also appear under [Requires human attention](/enrollment/overview/#requires-human-attention) on the Enrollment Overview. ## Related [Section titled “Related”](#related) * [Knowledge base](/enrollment/knowledge-base/) # Knowledge base > Manage the sources, documents and tags behind every Unifuse answer, upload documents for review, test what a source can answer, and read how the assistant cites and abstains. The knowledge base is the single library the assistant answers from, in the AI Front Door, in student conversations and on the Knowledge Base page itself. Documents come in through connected sources and uploads and are organised by tags. It is under **Enrollment → Knowledge Base**; **Student Success → Knowledge Base** shows the same library filtered to Student Success content. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view kb* to read and ask. Uploading, tagging, syncing and deleting need *manage kb* (Admin only by default). ## Data sources [Section titled “Data sources”](#data-sources) Source cards show document and chunk counts and the last error, if any. The **Explorer** tree and **Search documents by title** find individual documents; the **Tags** panel lists tags and lets an administrator add or delete them. **Add a Source** opens [Integrations](/integrations/overview/). Select a source to open its drawer: document, chunk and token counts; **Last crawl** with **Sync in background**; **Test this source**, which asks a question the source should be able to answer; and, for web sources, the page inventory with **Excluded paths**. Select a document to see its tags (attach or detach), its indexed chunks, and **Delete**. ## Upload a document [Section titled “Upload a document”](#upload-a-document) **Upload Document** accepts PDF, text, PNG and JPEG files up to 15 MiB. Every file is checked against its declared type and virus-scanned, and is stored encrypted. Scanned documents and images need text recognition, which Unifuse enables per institution. An upload does not enter the knowledge base until a reviewer with *manage kb* approves it on the review queue. Uploaded documents are attached to the built-in **Manual Uploads** source. ## Ask the knowledge base [Section titled “Ask the knowledge base”](#ask-the-knowledge-base) The **Ask the knowledge base** tab takes a question across all documents, or within the selected tags. The answer card shows: * the answer; * **Retrieval confidence** and the institution’s **threshold**: confidence is how closely the best-matching passage matches the question; * numbered **Sources** linking to the page or file; * when confidence is below the threshold, the assistant abstains. It does not guess; it refers the user to the contact the institution has set, such as a student-services email. Every question is logged. The abstain threshold and the fallback contact are set in the Orchestration Hub’s global configuration. ## Evaluation [Section titled “Evaluation”](#evaluation) Nightly evaluation runs ask the knowledge base a fixed set of questions and record which passed, which newly fail, and results by category. The evaluation page is at `/knowledge-base/evaluation`; **Run now** needs *manage kb*. ## Related [Section titled “Related”](#related) * [Connector catalogue](/integrations/connectors/) * [The AI Front Door](/ai-assistant/front-door/) # Enrollment Overview > The Enrollment Command dashboard in Unifuse: cycle selector, KPIs, the funnel, insights, custom metric widgets, quick actions, and the Requires human attention queue. **Enrollment → Overview** (titled **Enrollment Command**) is the enrollment leader’s dashboard. It draws on the Applicant CRM, the Enrollment Agent and the knowledge base. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view applicants*. ## Cycle selector [Section titled “Cycle selector”](#cycle-selector) Choose the admissions cycle to view. Applicant-based figures show the change against the previous cycle. The Enrollment Agent and Knowledge Base figures are not filtered by cycle and are marked **All terms**. ## Overview tab [Section titled “Overview tab”](#overview-tab) * **KPI row**: Total Applicants, Admitted, Agent Chats, KB Sources and Avg Progress, each with a supporting figure such as deposits paid or conversations needing review. * **Cards** for Applicant CRM, Enrollment Agent and Knowledge Base, each with **View**. * **Strategy Engine**: the four campaigns with the widest reach, with engagement and return. Select one for its details, or **View All Campaigns**. * **Enrollment Funnel**: inquiries, applicants, admitted and deposits, with yield rate, enrolled and average progress. * **EM Insights**: a saved feed of generated insights, with **Generate Insights** or **Refresh Insights**, and **Full Report** for a longer generated report. Reports are written only from the figures on the page; the assistant is not allowed to estimate. ## Customize [Section titled “Customize”](#customize) **Customize** opens the metric composer. Choose a metric (Applications, Admitted, Deposits, Yield Rate, Melt Rate), one or more breakdowns (time, state, student type, source channel, department) and a chart style, then **Add to Dashboard**. Saved widgets appear under **Active Widgets**, where they can be switched off or deleted. Widgets are saved per user. ## Quick Actions [Section titled “Quick Actions”](#quick-actions) **Create Campaign**, **Upload KB Source**, **Review Escalations** and **Process Documents** open the corresponding screens. ## Requires human attention [Section titled “Requires human attention”](#requires-human-attention) This tab gathers everything across Enrollment that is waiting for a person: campaign approvals, escalated agent conversations, document reviews, draft template approvals and knowledge-base questions the assistant could not answer confidently. Columns are Item, Submitted, Topic, Urgency and Assigned to. Select a row to open the review drawer, which shows the topic, urgency, when it was submitted and where it came from, lets you set **Assigned to** (needs *manage review queue*), and has a button that opens the item where it lives: Campaigns, Templates, Conversations, Document Analysis or Knowledge Base. ## Related [Section titled “Related”](#related) * [Applicant CRM](/enrollment/applicant-crm/) * [Campaigns](/enrollment/campaigns/) # Surveys > Build and publish surveys in Unifuse with multiple-choice, rating, NPS, yes/no and open-text questions, and track responses. **Campaign → Survey** is the survey builder. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view surveys* to look and *manage surveys* to build, publish and edit. ## The list [Section titled “The list”](#the-list) Cards for total surveys, active surveys and total responses, and a table with each survey’s status, question count, responses and response rate, with **Responses**, **Edit**, **Publish** or **Unpublish**, and **Delete**. ## Build a survey [Section titled “Build a survey”](#build-a-survey) 1. Select **New Survey**. 2. Enter the **Survey Name**, **Audience**, **Description** and **Audience Size**, and mark the **Channels** it is intended for. 3. Add questions: **Multiple choice**, **Rating scale**, **NPS (0–10)**, **Yes / No** or **Open text**. **Add option** adds choices; the arrows reorder questions. 4. **Save Draft**, or **Save & Publish**. A survey needs at least one question to publish. Response rate is responses divided by the audience size you entered. ## Collecting responses [Section titled “Collecting responses”](#collecting-responses) Publishing makes the survey active in Unifuse. Distributing it to respondents and recording their answers is done through your institution’s chosen channel with Unifuse support; the product does not yet send surveys or host a public response page. ## Related [Section titled “Related”](#related) * [Campaigns](/enrollment/campaigns/) # Roles and what they can see > The stock Unifuse roles (Admin, Advisor, Dean, Viewer, Student), what each one can do, and how permissions decide which screens appear. Everything you can see and do in Unifuse is decided by the permissions on your role. The sidebar only shows the areas you can open, and the server enforces the same permissions on every request, so hiding a screen is never the only protection. ## Stock roles [Section titled “Stock roles”](#stock-roles) Every institution starts with these roles. Administrators can change their permissions (except Admin) and create more. See [Roles](/administration/roles/). | Role | Purpose | Typical use | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | **Admin** | Full access, including every Administration screen. Its permissions cannot be edited. | The institution’s Unifuse owners. | | **Advisor** | View and manage assigned students, read the knowledge base, run campaigns and surveys, work with agents, approve routine agent actions, send messages, export data and read conversation logs. Cannot manage the knowledge base, grant student access, see Advancement or use Administration. | Advising and student-success staff. | | **Dean** | Read-only across all of the institution’s students, not just a caseload, with exports. No edits and no sending. | Leadership who need the whole picture. | | **Viewer** | Read-only across the hubs. No escalation, export, sending or unmasking of personal data. | Auditors, new starters. | | **Student** | The default role for anyone who signs in without a mapped role. Sees nothing in the staff workspace. | A safe landing role until an administrator assigns a real one. | ## How screens are gated [Section titled “How screens are gated”](#how-screens-are-gated) Each screen needs one permission. Some examples: * **Audit Logs** needs *view audit*, which only Admin holds by default. * **Integrations** needs *manage connectors*. * **Channels** needs *manage channels*. * The **Administration** link appears if you hold any of *manage institution*, *manage SCIM*, *manage roles* or *manage users*, and each Administration tab is shown only to the permissions it needs. Changes to a role’s permissions take effect on the next request. Nobody has to sign out and back in. ## Student scope [Section titled “Student scope”](#student-scope) Advisors see the students assigned to them. Roles with *full student access* (Admin and Dean by default) see every student at the institution. ## Related [Section titled “Related”](#related) * [Roles](/administration/roles/) for editing the permission matrix * [Users](/administration/users/) for assigning roles # Signing in > How to sign in to Unifuse with your institution's single sign-on, what happens the first time, and what the sign-in messages mean. Unifuse signs you in through your institution’s identity provider. There are no Unifuse passwords to create, remember or reset: if you can sign in to your institution’s systems, you can sign in to Unifuse. ## Before you start [Section titled “Before you start”](#before-you-start) * You need a work email address at an institution that uses Unifuse. * Your institution’s administrator must have connected its identity provider to Unifuse (see [Single sign-on](/administration/single-sign-on/)). ## Sign in [Section titled “Sign in”](#sign-in) 1. Open your institution’s Unifuse address in a browser. 2. In **Work Email**, enter your institutional email address. 3. Select **Continue with SSO**. Unifuse looks up your institution from the email domain and sends you to its identity provider. 4. Sign in there as you normally would. You are returned to Unifuse and land on your home page. The email address you enter must match the account your identity provider signs you in with. If they differ, sign-in fails and you are asked to try again with the matching address. ## The first time you sign in [Section titled “The first time you sign in”](#the-first-time-you-sign-in) Your Unifuse account is created automatically the first time your identity provider confirms who you are. Your name and email come from the identity provider. What you can see depends on your role. If your institution maps identity-provider attributes to Unifuse roles, you get that role straight away. Otherwise you get the institution’s default role, which is **Student** unless an administrator has changed it. The Student role has no access to the staff workspace, so you will see a page saying your administrator has not given you access yet. Ask your administrator to assign you a role; you do not need to sign in again afterwards. ## Sign-in messages [Section titled “Sign-in messages”](#sign-in-messages) | Message | What it means | | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No single sign-on is configured for this email address. | Either the email domain is not registered with Unifuse, or the institution has not connected an identity provider yet. The same message is shown in both cases. | | This account has been deactivated. | Your institution has deactivated your Unifuse account. Signing in at the identity provider does not reactivate it; ask your administrator. | | You were signed out, either after a period of inactivity or by your administrator. | Your session ended. Sign in again. See [Session policy](/administration/session-policy/) for how long sessions last. | | Sign-in failed. Please try again. | A general failure. If it repeats, your administrator can find the reason in the audit log. | Every failed sign-in is recorded in your institution’s audit log. ## Two-factor authentication [Section titled “Two-factor authentication”](#two-factor-authentication) You can add an authenticator app to your account under **Settings → Security → Turn on two-factor**. Unifuse shows a secret to enter in your app, asks for a six-digit code to confirm, and then shows a set of backup codes once. Keep them somewhere safe. Turning two-factor off again requires a current code or a backup code. Note Two-factor authentication at the identity provider is what protects sign-in. The authenticator you add in Unifuse is recorded on your account but is not currently asked for as a separate step when you sign in. ## Related [Section titled “Related”](#related) * [Your account](/getting-started/your-account/) * [Roles and what they can see](/getting-started/roles/) # Your account > What you can manage under Settings in Unifuse: your profile, active sessions, two-factor authentication, notification preferences, and your own data. Open **Settings** from the user menu at the bottom of the sidebar. The personal tabs are **My Profile**, **Security** and **Notifications**. Administrators also see **Team & Roles**, which opens the [Administration](/administration/overview/) page. ## My Profile [Section titled “My Profile”](#my-profile) Your name and email are read-only. They come from your institution’s identity provider or its provisioning system, so changes are made there and flow through on your next sign-in or sync. Under **Your data**: * **Download my data** gives you a file of the student and applicant records Unifuse holds about you. * **Request erasure** asks your institution to erase your personal data. Unifuse shows a confirmation, creates a request with a reference number and a 30-day due date, and notifies your institution’s administrators. If you already have an open request, pressing the button again shows the same request. See [Privacy requests](/administration/privacy-requests/) for what the institution does next. ## Security [Section titled “Security”](#security) * **Active sessions** lists every place you are signed in, with the device, network address and sign-in time. **Revoke** ends one session; **Sign out everywhere** ends them all. * **Two-factor** lets you add an authenticator app and get backup codes. See [Signing in](/getting-started/signing-in/#two-factor-authentication) for what this does and does not do. ## Notifications [Section titled “Notifications”](#notifications) Choose, per category, whether to be notified in the app, by email, or both. The bell in the header shows unread in-app notifications and takes you to the item each one is about. ## Sessions and timeouts [Section titled “Sessions and timeouts”](#sessions-and-timeouts) Your session ends after a period of inactivity, after a maximum length from sign-in, or when an administrator signs you out. Only your own actions count as activity. There is no warning before an idle timeout; you are returned to the sign-in page with a message explaining why. Your institution sets the limits; see [Session policy](/administration/session-policy/). ## What’s new [Section titled “What’s new”](#whats-new) **What’s new** in the user menu shows the release notes for the version you are using, pulled from the [Unifuse changelog](https://changelog.unifuse.ai/). # Channels and web chat > Set up the channels students use to reach your institution through Unifuse: an SMS number and the embeddable web chat widget, with allowed origins, greetings, key rotation and limits. Students reach the assistant by texting your institution’s number or through a chat widget on your website. Both are **deployments**, managed under **Administration → Channels**. The **Channels** page in the sidebar shows every channel, whether it is configured, and recent redacted conversations. ## Before you start [Section titled “Before you start”](#before-you-start) * Managing deployments needs *manage channels*. * Answers to anonymous visitors come only from knowledge-base sources marked **public**. Mark the right sources before going live; see [Integrations overview](/integrations/overview/#sensitivity). * Decide whether replies should wait for a person (**Calibration**, the default) or go out directly (**Auto**). See [Contact policy](/administration/contact-policy/#assistant-replies). ## Add a deployment [Section titled “Add a deployment”](#add-a-deployment) 1. Select **Add deployment**. 2. Choose the **Channel**: **SMS number** or **Web chat widget**. 3. Enter a **Name**. 4. For SMS, enter the **Phone number** in international format. Unifuse provisions the number with its messaging provider during onboarding. 5. For web chat, enter the **Allowed origins**: the sites the widget may load on, up to 20. 6. Optionally enter a **Greeting**, up to 500 characters, shown when the widget opens. The default tells the visitor that a person reviews the assistant’s answers. 7. Select **Add deployment**. The table lists each deployment’s channel, name, address, an **Active** toggle, and for web chat **Copy snippet** and **Rotate key**. Deployments can be deactivated but not deleted. Every change is recorded in the audit log. ## Embed the widget [Section titled “Embed the widget”](#embed-the-widget) Paste the snippet from **Copy snippet** before the closing `` tag of each page. Your site’s content security policy must allow the Unifuse origin in `script-src` and `frame-src`. The widget is a chat button fixed at the bottom right of the page, isolated from your site’s styles, which opens a panel titled “Chat with us”. It respects reduced-motion settings and resizes on small screens. **Rotate key** issues a new key and stops the old snippet immediately. Use it if a snippet has been copied somewhere it should not be. ## What visitors experience [Section titled “What visitors experience”](#what-visitors-experience) * The panel header shows your institution and the deployment name. In calibration mode it shows **Answers reviewed by a person**, and a pending line while a reply is in the Review Queue. * Messages are limited to 2,000 characters. * Rate limits apply per visitor and per deployment; a visitor who exceeds them is asked to wait a moment. * The conversation lives only in that browser tab. * A visitor who matches a student record must verify with a one-time code before the assistant looks anything up about them. * Texting STOP opts a number out; START opts it back in. ## Other channels [Section titled “Other channels”](#other-channels) The Channels page also lists Email (outbound only; inbound email is not a channel yet), Microsoft Teams, Slack, WhatsApp and Voice. These show as not configured unless Unifuse has set them up for your institution. ## Related [Section titled “Related”](#related) * [Review Queue](/student-success/review-queue/) * [Contact policy](/administration/contact-policy/) # Connector catalogue > Every system Unifuse can connect to, what each connector needs from you, what it brings in, and which ones can write back. Connectors are added from **Integrations → Add Source**. This page lists what each one asks for and what it does. Required fields are marked with an asterisk. ## Document and storage sources [Section titled “Document and storage sources”](#document-and-storage-sources) These feed the knowledge base. | Connector | Signs in with | What you enter | Notes | | ------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | | **Web Crawl** | Nothing | Seed URLs\*; Max depth (default 1); Same domain only; Max pages (default 50); Crawl delay in seconds (default 0.5); Respect robots.txt (default on); Max page size (default 5 MiB); Recrawl every N hours (default 24, 0 for never); Sensitivity | Public websites, such as your catalogue or policies. | | **Google Drive** | Google OAuth, read-only Drive access | Folder IDs\*; Sensitivity | | | **SharePoint** | Microsoft OAuth, read access to sites and files | Site ID\*; Drive ID\*; Sensitivity | | | **Google Calendar** | Google OAuth, read-only calendar access | Calendar ID (default `primary`); Days ahead (default 60); Sensitivity | Events become answerable content. | | **SFTP / FTPS** | Username and password | Protocol (`sftp` default, or `ftps`); Host\*; Port; Remote directory (default `/`); Username\*; Password\*; Sensitivity | Encrypted transfer only. Can also push files. | | **Box** | Box OAuth | Folder IDs\* (`0` is the root); Sensitivity | Can also upload files. | | **MCP Server** | Optional bearer token | Server URL\*; Bearer token; Sensitivity | Any server that speaks the Model Context Protocol over HTTP. | | **Zendesk** | Agent email and API token | Subdomain\*; Agent email\*; API token\*; Sensitivity; Writable fields | Tickets become answerable content. Can create and update tickets. | | **Jira** | Account email and API token | Base URL\*; Account email\*; JQL filter; Default project key; API token\*; Sensitivity; Writable fields | Issues become answerable content. Can create and update issues. | Files uploaded by hand on the Knowledge Base page appear under a built-in **Manual Uploads** source. ## Student information and CRM sources [Section titled “Student information and CRM sources”](#student-information-and-crm-sources) These feed student and applicant records. | Connector | Signs in with | What you enter | Notes | | --------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | **Banner / LMS nightly extract (SFTP)** | Username and password | The SFTP fields above, plus file-name patterns for the Student, Registrations, LMS activity and LMS attendance files, and Alert recipients | The recommended path for Banner and LMS data. See [SIS and LMS data](/integrations/sis-and-lms-data/). | | **Ellucian Banner (Ethos)** | Ethos API key | Ethos base URL\*; Ethos API key\*; Sensitivity | Student records over the Ethos API. | | **Ellucian Colleague (Ethos)** | Ethos API key | As for Banner | | | **Slate (Technolutions)** | API username and password | Slate query URL\*; API username\*; API password\* | Applicant records from a Slate query. | | **Salesforce (Education Cloud)** | Salesforce OAuth | Instance URL (filled in after sign-in); Lead query override; Writable fields | Applicant and student records. Can create leads and update contacts. | | **Oracle PeopleSoft** | Username and password | Base URL\*; Students path; Write path; Username\*; Password\*; Writable fields | Student records. Can update students. | | **Workday Student** | Integration system user | RaaS report URL\*; Write endpoint URL; ISU username\*; ISU password\*; Writable fields | Student records from a Report-as-a-Service report. Can update students. | ## Learning management systems [Section titled “Learning management systems”](#learning-management-systems) LMS activity and attendance arrive through the nightly extract as CSV files, in the layout most LMS platforms export. There is no direct LMS API connector at present. ## Writing back [Section titled “Writing back”](#writing-back) Connectors marked as able to create or update records only do so through fields listed in **Writable fields**, which is empty by default. Leave it empty to keep a connector read-only. Write-back actions are governed by [trust tiers](/ai-assistant/approvals/) and recorded in the audit log. ## Related [Section titled “Related”](#related) * [Integrations overview](/integrations/overview/) # Integrations overview > How the Integrations screen in Unifuse works: adding a source from the connector catalogue, the connector drawer, health checks, syncing and disconnecting. **Integrations** in the sidebar is where an institution connects the systems that feed Unifuse: document sources for the knowledge base, and the student information, CRM and service-desk systems that feed student and applicant records. ## Before you start [Section titled “Before you start”](#before-you-start) * Opening the screen needs *manage institution*; adding, syncing, changing and disconnecting sources needs *manage connectors*. * Have the credentials for the system you are connecting. The [connector catalogue](/integrations/connectors/) lists what each one asks for. ## Add a source [Section titled “Add a source”](#add-a-source) 1. Select **Add Source**. 2. Choose the **Connector**. Connectors that sign in with OAuth are marked. 3. Enter a **Name** that will identify this source, for example “Admissions Drive”. 4. Fill in the connector’s fields. Required fields are marked. Secret fields are entered as passwords and stored encrypted, separately from the rest of the configuration. 5. Select **Create Source**. For an OAuth connector, the browser then goes to the provider’s consent screen and returns to Integrations with a success or failure notice. Other connectors are connected as soon as they are created. ## The source cards [Section titled “The source cards”](#the-source-cards) Each source is a card showing its status (Connected, Syncing, Disconnected or Error), the connector, the last sync time and a health line: healthy with the last check time, a failed check with the reason, or “not supported” for connectors that have no health probe. Select a card to open the connector drawer, which shows the status, connection details, last sync and last error, the configuration (editable, with **Name** and the connector’s fields), and the actions: * **Connect**: complete authorisation for an OAuth source that needs it. * **Test**: run the health check now. * **Sync**: run a sync now. * **Disconnect**: remove the source. For a document source this also purges every document and embedding it contributed to the knowledge base. ## When sources sync [Section titled “When sources sync”](#when-sources-sync) * Document sources are re-synced on a schedule, by default every 24 hours; the Web Crawl connector has its own **Recrawl every** setting. * Record sources (SIS and CRM connectors) sync when you select **Sync**. The nightly SIS and LMS extract over SFTP runs on its own schedule; see [SIS and LMS data](/integrations/sis-and-lms-data/). * Health checks run hourly. ## Sensitivity [Section titled “Sensitivity”](#sensitivity) Most connectors have a **Sensitivity** field, default `internal`. It becomes a tag on every document from that source. Only sources set to `public` can be used to answer anonymous visitors through the web chat widget or the SMS line. ## Related [Section titled “Related”](#related) * [Connector catalogue](/integrations/connectors/) * [Knowledge base](/enrollment/knowledge-base/) # SIS and LMS data > How the nightly student information system and learning management system extract reaches Unifuse over SFTP, the four files it expects, how imports are validated, and what you are alerted about. The nightly extract is how most institutions give Unifuse their SIS and LMS data. Your registrar or IT team drops CSV files on an SFTP server each night; Unifuse picks them up, validates them and updates student records. ## Before you start [Section titled “Before you start”](#before-you-start) * Add the **Banner / LMS nightly extract (SFTP)** connector under Integrations with the SFTP host, credentials and directory, the file-name patterns, and the email addresses to alert. * Agree the column layouts with Unifuse support during onboarding. Unifuse keeps the agreed column list for your institution so the registrar has a single reference. ## The four files [Section titled “The four files”](#the-four-files) | File | Default pattern | Content | | -------------- | --------------------- | --------------------------------------------------------------------------------------------- | | Students | `*students*.csv` | One row per student, in Banner column names (ID, name, term, GPA, standing and so on). | | Registrations | `*registrations*.csv` | One row per student per course section, with the course reference number. | | LMS activity | `*activity*.csv` | Per student per section: current score; on-time, late and missing submissions; last activity. | | LMS attendance | `*attendance*.csv` | Per student per section per date: status and minutes present. | Patterns match the file name only and ignore case, so dated file names need no change. Files load in the order above each night. ## How an import is validated [Section titled “How an import is validated”](#how-an-import-is-validated) * A file presented twice is ignored the second time; Unifuse matches on the file’s content. * Column order, letter case and surrounding whitespace do not matter. A renamed or missing column halts that file. * Malformed rows are quarantined and the rest of the file is imported. When a file has quarantined rows, the “mark missing students inactive” step is skipped for that night, so a bad file never deactivates students by accident. * A student missing from the students file is marked **Inactive**, never deleted. Notes, tags, escalations and caseload assignments survive. ## Alerts [Section titled “Alerts”](#alerts) When a file halts or rows are quarantined, Unifuse emails the alert recipients, writes a Critical entry in the audit log, and shows a red item in the notification bell for everyone with *manage connectors*. ## Retention [Section titled “Retention”](#retention) Staged and quarantined rows are kept for 30 days and then purged. Batch summaries are kept. ## What you see in the product [Section titled “What you see in the product”](#what-you-see-in-the-product) The student record shows SIS and LMS data side by side, with **Not on file** wherever the latest import had nothing. The roster gains LMS Score and Attendance columns, and the nightly risk job uses the new data to place students in [cohorts](/student-success/risk-cohorts/). ## Related [Section titled “Related”](#related) * [Connector catalogue](/integrations/connectors/) * [The student record](/student-success/student-record/) # Workspace > Connect Google Workspace or Microsoft 365 to Unifuse once for the whole institution, for document access and staff calendar availability. The **Workspace** tab under Administration connects your institution’s Google Workspace or Microsoft 365 tenant once, so that document sources and staff calendar availability work without each member of staff connecting their own account. It is not used for sign-in; see [Single sign-on](/administration/single-sign-on/). ## Before you start [Section titled “Before you start”](#before-you-start) * You need *manage connectors*. * You need an administrator of your Google Workspace or Microsoft 365 tenant. ## Google Workspace [Section titled “Google Workspace”](#google-workspace) Unifuse uses domain-wide delegation with read-only scopes. 1. In the Google Admin console, under API controls, add a domain-wide delegation client using the **Client ID** shown on the tab (there is a copy button). 2. Authorise exactly the two scopes shown: read-only Calendar and read-only Drive. 3. On the tab, enter your **Workspace domain** (for example `yourschool.edu`) and an **admin email** to act as, then **Save** and **Verify connection**. The card shows **Connected**, **Error** or **Disconnected**, and when it was last verified. **Disconnect** removes the connection. ## Microsoft 365 [Section titled “Microsoft 365”](#microsoft-365) A Global Administrator selects **Connect Microsoft 365** and grants admin consent once for the application permissions to read calendars, files and sites. The card then shows the connected tenant. ## Related [Section titled “Related”](#related) * [Appointments](/student-success/appointments/) for per-user calendar connections * [Connector catalogue](/integrations/connectors/) # Advisor Brief > Use the weekly Advisor Brief in Unifuse to see which students need help now, which are slipping and which are excelling, take the recommended action, claim a student for the week, and export or email the brief. The Advisor Brief is the first tab of Success Center. Each week it lists the students on your caseload whose SIS and LMS signals changed, why they are listed, and one recommended next step for each. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view students*. Taking action needs the permission of that action (see below). * Rows appear after the nightly risk job has run over your institution’s SIS and LMS imports. A new institution sees an empty brief until the first import has landed. ## Reading the brief [Section titled “Reading the brief”](#reading-the-brief) The heading reads **Your brief for the week**, with a summary line: how many need help now, how many are slipping, how many are handled so far, the date the data is from, and the week number. Four lanes: | Lane | Who is in it | | ------------------ | --------------------------------------------------------------- | | **Needs help now** | Students in this week’s *at risk* cohort. | | **Slipping** | Students on the *probation cusp*. | | **Excelling** | Students *doing well* with a positive signal worth recognising. | | **Handled** | Anyone claimed this week. | Each row shows the student, **Why they’re here** (the lead reason and a due badge of **Today** for a critical signal or **This week** otherwise), the **Recommended action** with a **Draft ready** badge when a message has been drafted, the **Status** (open, or who claimed it and when), and **I’ll handle it**. **Search** looks across all lanes. ## Take the recommended action [Section titled “Take the recommended action”](#take-the-recommended-action) The action is chosen from the row’s lead reason, and opens an existing screen with the details already filled in: * **Draft outreach** opens the message composer (needs *send messages*). See [Messaging students](/student-success/messaging-students/). * **Add a note** opens the notes panel (needs *manage students*). * **Escalate** opens the escalation dialog with the reason and urgency filled in (needs *escalate students*). * **Schedule a follow-up** opens the appointment wizard (needs *manage appointments*). ## Claim a student [Section titled “Claim a student”](#claim-a-student) **I’ll handle it** (needs *manage students*) claims the student for the current week, writes a note on their record, and moves the row to **Handled** for everyone who can see that student. If two people claim at the same moment, the first wins. A student still flagged next week comes back unclaimed. ## Header controls [Section titled “Header controls”](#header-controls) * **My caseload / Institution** switches scope, for roles with *full student access*. * **Monday email** turns on a weekly digest at 7:00 AM Eastern with the top five open rows from the first two lanes. It is the same setting as *Advisor Brief* under Settings → Notifications. The digest has to be activated for your institution by Unifuse. * **Draft this week’s messages** (needs *manage students*) asks the assistant to write a draft for every open outreach row. Drafts are written from redacted data and nothing is sent: the composer opens pre-filled when you choose the row. * **Export and share** offers **Export to PDF**, **Export to Excel** (both need *export data*, are produced for your scope only, and are recorded in the audit log) and **Email me this brief**. ## Related [Section titled “Related”](#related) * [The student record](/student-success/student-record/) * [Messaging students](/student-success/messaging-students/) # Appointments > Schedule and manage advising appointments in Unifuse, connect your calendar, and send reminders through the contact policy. **Student Success → Appointments** is the advising calendar. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view appointments* to open it and *manage appointments* to create or change appointments. ## What you see [Section titled “What you see”](#what-you-see) * A dashboard for the week: this week’s appointments, with toggles for no-shows and cancellations, the most common types, students without appointments, and a banner for scheduling conflicts. * A calendar grid with a filter by appointment type. * A calendar bar showing whether your calendar is connected, with **Connect Google Calendar** or **Connect Microsoft 365** for your own availability. ## Create an appointment [Section titled “Create an appointment”](#create-an-appointment) **New Appointment** opens an eight-step wizard that picks the advisor, the student from the roster, an available slot, the type and the details, then saves the appointment. ## Manage an appointment [Section titled “Manage an appointment”](#manage-an-appointment) Select an appointment to open its panel: add notes, **Complete**, **Reschedule** or **Cancel** with a reason. ## Reminders and nudges [Section titled “Reminders and nudges”](#reminders-and-nudges) **Send reminder** and the **Nudge** action for students without appointments go through the contact policy like any other message. See [Messaging students](/student-success/messaging-students/). ## Related [Section titled “Related”](#related) * [Workspace](/integrations/workspace/) for an institution-wide calendar connection # Messaging students > Send a message to a student from Unifuse by email or text, and understand the contact gate every message passes through: consent, budget, quiet hours and review. Staff message students from several places in Unifuse: **Send nudge** on the student record, **Draft outreach** in the Advisor Brief, reminders in Appointments, the AI assistant, and campaigns. Every one of these goes through the institution’s contact policy before anything is sent. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *send messages*. * The student must have an email address or phone number on file for the channel you choose. ## The composer [Section titled “The composer”](#the-composer) The dialog is titled **Message **, with the note that it goes through your institution’s contact policy. 1. Choose **Send by**: **Email** or **Text message**. A channel with nothing on file is marked as such. 2. For email, enter a **Subject**. 3. Write the **Message**, then select **Send**. ## What happens next [Section titled “What happens next”](#what-happens-next) | Result | Meaning | | -------------------- | ---------------------------------------------------------------------------------------------- | | Sent | The message went out and is on the student’s contact history. | | Delivered | The provider confirmed delivery. | | Scheduled | It is quiet hours; the message goes when they end. | | Held for review | The student’s message budget for the window is used up. The message waits in the Review Queue. | | Waiting for approval | The message needs approval before it goes. | | Not sent | The reason is shown, for example the student has opted out. | ## The contact gate [Section titled “The contact gate”](#the-contact-gate) Checks run in this order: 1. **Consent.** A student who has opted out of a channel (for example by texting STOP) is never messaged on it. Opt-outs cannot be overridden. 2. **Category.** Replies to a student who wrote in are not budgeted and ignore quiet hours. Transactional messages (such as appointment reminders) are not budgeted but respect quiet hours. Proactive outreach uses the budget. 3. **Budget and spacing.** By default one proactive message per student per seven days, at least 24 hours apart, across all channels. 4. **Collision.** Two pending drafts to the same student are merged; conflicting ones are held. 5. **Approval.** Where the institution requires it. 6. **Quiet hours.** By default 21:00 to 08:00 Eastern; messages are deferred until they end. Staff can send past the budget and quiet hours if the institution allows overrides, by giving a reason that is recorded in the audit log. Students can text STOP (also stopall, unsubscribe, cancel, end, quit) to opt out of texts and START (also unstop, yes, subscribe) to opt back in. Campaign emails carry an unsubscribe link. ## Related [Section titled “Related”](#related) * [Contact policy](/administration/contact-policy/) for the institution’s settings * [Review Queue](/student-success/review-queue/) # My Students > Search, filter and query the Unifuse student roster, read the SIS and LMS columns, and understand the Inactive and Not on file markers. **My Students** is the roster tab of Success Center: every student in your scope, with the columns your SIS and LMS imports supply. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *view students*. * Data is as fresh as the last nightly import; the banner at the top shows when it ran. ## Summary cards [Section titled “Summary cards”](#summary-cards) **Total Students**, **At-Risk**, **Avg GPA**, **Avg LMS Logins (/wk)**, **Thriving** and **Retention**. The Retention figure is the share of students not currently flagged at risk; it is not a prediction. ## Find students [Section titled “Find students”](#find-students) * **Search** by name, ID, major or email. * Filters for **Risk Level**, **Cohort** (At risk, Probation cusp, Doing well), **Status** (At-Risk, Watchlist, On-Track, Thriving) and **Year**. * **AI Query** takes a plain-English question such as “freshmen with GPA below 2.0” and turns it into filters. Chips then show how the question was understood; **Clear** removes them. ## Columns [Section titled “Columns”](#columns) Student · Major / Year · GPA · Risk Score · Risk Level · Status · Cohort · LMS Score · Attendance · Tags · Last Contact · Actions. * **Cohort** is the weekly signal Unifuse derives from your SIS and LMS data. See [Risk cohorts](/student-success/risk-cohorts/). * **Risk Score** and **Risk Level** come from your CRM or SIS data as imported. * **Inactive** means the student was missing from the latest SIS extract. The record, notes and history are kept. * **Not on file** means the latest LMS import had no data for that student. Select a student to open their [record](/student-success/student-record/). ## Related [Section titled “Related”](#related) * [Success Center](/student-success/success-center/) # Review Queue > Review, edit, approve or reject the replies the Unifuse assistant drafts for students who text or use web chat, and release messages held by the contact policy. When a student texts your institution’s number or uses the web chat widget, the assistant drafts a reply grounded in the knowledge base. In calibration mode (the default), every draft waits in the Review Queue for a person to approve it. The queue also holds staff messages that the contact policy paused. ## Before you start [Section titled “Before you start”](#before-you-start) * You need *manage review queue* (Advisor has it by default). * Open **Conversation Intelligence → Review Queue**. Quick routes in: **Review Escalations** under Enrollment Overview’s quick actions, or **Open all transcripts** on the Channels page. ## How student conversations work [Section titled “How student conversations work”](#how-student-conversations-work) * Anonymous senders get answers only from knowledge-base sources marked public. * A sender who matches a student record must verify with a one-time code before the assistant looks anything up about them. * Each draft carries its sources and a confidence label: high, medium, low, or **abstained** when the assistant found nothing it could answer from. ## The queue [Section titled “The queue”](#the-queue) Columns: Question · From · Channel · Deployment · Confidence · Age · Status. Select a row to open the drawer, which shows **Conversation so far** and the **Drafted reply** with its **Sources**. ## Decide [Section titled “Decide”](#decide) * **Approve and send** sends the draft. If you edit the text first, the button becomes **Approve with edits**; **Reset edits** restores the draft. * **Reject reply** discards the draft; a reason is optional. Nothing is sent and the draft stays on the record. * For a staff message held by the contact policy: **Release** sends it; **Discard** drops it. * **Previous** and **Next** move through the queue. Text replies are limited to 320 characters including one source line; the editor’s counter enforces it. ## Related [Section titled “Related”](#related) * [Contact policy](/administration/contact-policy/) to switch between calibration and auto * [Channels and web chat](/integrations/channels/) # Risk cohorts > How Unifuse places each student in a weekly risk cohort from SIS and LMS signals, the reason codes it uses, and the default thresholds an institution can change. Every night, after the SIS and LMS imports, Unifuse places each student in one of three cohorts for the week. The cohort and its reasons drive the Advisor Brief, the Dashboard and the Weekly Risk Cohort card on the student record. ## Cohorts [Section titled “Cohorts”](#cohorts) * **At risk** * **Probation cusp** * **Doing well** ## Reason codes [Section titled “Reason codes”](#reason-codes) | Severity | Reasons | | -------- | ------------------------------------------------------------------------------------------ | | Critical | Term GPA under the probation line · On academic probation · Attendance fell week over week | | Warning | Attendance below threshold · Missing LMS submissions · No recent LMS activity | | Cusp | Term or cumulative GPA near the probation line · Academic standing warning | | Positive | Strong GPA · Strong attendance · Submissions up to date · Recently active in the LMS | A student with a critical reason, or two or more warnings, is placed at risk. ## Default thresholds [Section titled “Default thresholds”](#default-thresholds) | Threshold | Default | | ------------------------------ | ------------------------------------ | | Probation GPA | 2.0, with a margin of 0.3 for “near” | | Attendance drop week over week | 30% | | Attendance below | 75% | | Missing submissions | 2 or more | | No LMS activity for | 14 days | Thresholds are set per institution during onboarding. Ask Unifuse support to change them. ## What the cohort is not [Section titled “What the cohort is not”](#what-the-cohort-is-not) The **Risk Score** and **Risk Level** columns are separate fields imported from your CRM or SIS. The cohort is the signal Unifuse derives itself from the SIS and LMS data it receives. ## Related [Section titled “Related”](#related) * [SIS and LMS data](/integrations/sis-and-lms-data/) # The student record > What the Unifuse student record shows from your SIS, LMS and Unifuse's own data, the actions available on it, and what "Not on file" and "Hidden" mean. The student record opens as an overlay from any list, and also as its own page. It brings together what your student information system (SIS) and learning management system (LMS) report, and what your staff have recorded in Unifuse. SIS and LMS data are read-only in Unifuse. Unifuse stores only its own data: notes, tags, escalations, appointments and outreach history. ## Header [Section titled “Header”](#header) Name and ID; program, cohort and EdTech platform; badges for status, risk level, this week’s cohort, enrollment status and **Inactive in SIS**; tag chips with suggestions; and stat cards for cumulative GPA, attendance, risk score and class rank. ## Actions [Section titled “Actions”](#actions) | Button | What it does | Permission | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | **Add note** | Opens the note composer. | manage students | | **Send nudge** | Opens the message composer. See [Messaging students](/student-success/messaging-students/). | send messages | | **Schedule meeting** | Opens the appointment wizard. | manage appointments | | **Escalate** | Opens the escalation dialog: **Escalate to**, **Reason** (required) and **Urgency** (low, medium, high, critical). The email sent carries the student’s name, ID, urgency and reason only; scores and notes stay behind sign-in. | escalate students | | **Configure cards** | Choose which cards and fields are shown for the whole institution. | manage institution | Buttons you cannot use are greyed out with an explanation. ## Cards [Section titled “Cards”](#cards) | Card | Source | What it shows | | ------------------------ | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Banner (SIS) | SIS | ID, name, email, phone, major, class, level, standing, enrolment, credits, terms | | LMS | LMS | Attendance rate; present, late, absent and excused counts; days recorded; last LMS activity | | Enrollment & Application | SIS | Application date and status, admission term, source, enrolled date, enrollment status, expected graduation | | EdTech Engagement | EdTech platform | Hours, completion, streaks, average session, last login, certificates | | Activity Timeline | Unifuse | Notes, escalations, appointments, outreach, assistant conversations and cohort moves, with **View all** | | Weekly Risk Cohort | Unifuse | This week’s cohort, its reason codes and where the student moved from | | Advisor Notes | Unifuse | Notes with author and time; **Pin to top** | | Escalations | Unifuse | Open cases with **Mark In Review**, **Resolve** and **Reopen** | | Communication | Unifuse | Sent, delivered, replied and response rate over 90 days by channel; last contact; last reply; **Opted out**. Counts only, never message text | | Courses | SIS and LMS | Code, course, credits, grade, status, and on-time, late and missing submissions. SIS and LMS rows are matched on the course reference number; dropped courses are dimmed | | Attendance | LMS | A one-year heatmap and monthly rates | | Academic Results | SIS | Term and cumulative GPA and grades by term | | Career Engagement | Unifuse | Locked unless the Career module is on | ## Conventions [Section titled “Conventions”](#conventions) * **Not on file**: no import has supplied this field yet. * **Hidden**: the field is withheld by your role or by institution settings. Sensitive fields are marked **Managers only** in the configure drawer. * Administrators can mask SIS IDs to their last four digits. ## Related [Section titled “Related”](#related) * [Risk cohorts](/student-success/risk-cohorts/) * [SIS and LMS data](/integrations/sis-and-lms-data/) # Success Center > The Student Success workspace in Unifuse: the Advisor Brief, Dashboard, My Students, Interventions and Reporting Dashboard tabs, and the caseload rule that decides which students you see. **Student Success → Success Center** is the daily workspace for advisors and student-success staff. It has five tabs, and the tab you are on is kept in the page address so the browser’s Back button and bookmarks work. | Tab | What it is for | | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Advisor Brief](/student-success/advisor-brief/) (default) | The students who need attention this week, each with a recommended action. | | Dashboard | Live tiles for your caseload: active caseload, at risk, watchlist, thriving, escalations awaiting review, cohort moves this week. Each tile opens the matching filtered list. **Customize** shows or hides tiles and remembers your choice. Cards below show the weekly risk cohorts with their top reasons, generated insights, and “where to look first”. | | [My Students](/student-success/my-students/) | The roster, with filters, natural-language queries and the columns that come from your SIS and LMS. | | Interventions | Read-only monitoring of deployed intervention agents: engagement funnel, channel and grade-level breakdowns, engagement buckets and intervention performance. | | Reporting Dashboard | A report builder (name, metric category, data points, date range, filters, cohort), saved reports, scheduled delivery by email, and CSV export for roles with *export data*. | ## Which students you see [Section titled “Which students you see”](#which-students-you-see) * An **Advisor** sees the students assigned to their caseload. * Roles with *full student access* (**Admin** and **Dean** by default) see every student at the institution. The same rule applies everywhere: the roster, the brief, reports and the AI assistant’s student tools. Students imported from your SIS start on nobody’s caseload; Unifuse support assigns caseloads during onboarding. ## Permissions used on these screens [Section titled “Permissions used on these screens”](#permissions-used-on-these-screens) | Action | Permission | | ---------------------------------------------- | ------------------- | | Open Success Center | view students | | Add notes, claim brief rows, generate insights | manage students | | Send messages | send messages | | Escalate a student | escalate students | | Schedule appointments | manage appointments | | Export reports and briefs | export data | Buttons you lack the permission for are shown greyed out with an explanation, not hidden. ## Related [Section titled “Related”](#related) * [Roles and what they can see](/getting-started/roles/) * [The student record](/student-success/student-record/) # Accessibility > Unifuse's accessibility commitments, what is built into the product, the conformance report available to institutions, and how this documentation site is tested. Unifuse is built for institutions that are required to meet WCAG 2.2 AA, and that standard is the product’s target. ## In the product [Section titled “In the product”](#in-the-product) * A skip link, landmarks for navigation and main content, and a distinct page title on every screen. * Visible focus indicators that meet contrast requirements, including on the dark sidebar. * Dialogs and drawers that trap focus, close with Escape and return focus where it was. * Labelled form fields with hints and error messages; switches, tabs and pressed states exposed to assistive technology; labelled icon-only buttons. * Live announcements for loading states, confirmations and interpreted queries. * Data tables behind every chart. * A layout that reflows to 320 pixels wide, with the sidebar becoming an off-canvas menu. * Respect for reduced-motion settings. ## Conformance report [Section titled “Conformance report”](#conformance-report) An Accessibility Conformance Report (VPAT 2.5 format, against WCAG 2.2 AA) is available to institutions on request through your Unifuse contact. Findings from each report are tracked and fixed in subsequent releases; see the [changelog](https://changelog.unifuse.ai/). ## This site [Section titled “This site”](#this-site) Every page of this documentation is tested on each change with an automated WCAG 2.2 AA audit in light and dark colour schemes, at desktop and 320-pixel widths, and a change that introduces a violation cannot be published. ## Feedback [Section titled “Feedback”](#feedback) If anything in Unifuse or in this documentation is hard to use with assistive technology, email with the page and what happened. # Data handling > What data Unifuse holds for an institution, where it comes from, how long it is kept, how individuals' erasure requests are handled, and what happens when an institution leaves. ## What Unifuse holds [Section titled “What Unifuse holds”](#what-unifuse-holds) | Data | Source | Notes | | ----------------------------- | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Student and applicant records | Your SIS, LMS and CRM, through the connectors you configure | Read-only copies. Unifuse never writes to these systems unless you list writable fields. | | Staff accounts | Your identity provider | Name, email, department, role. | | Knowledge-base content | The document sources you connect and files you upload | Tagged with the sensitivity you set per source. | | Unifuse’s own records | Created by your staff and the assistant | Notes, tags, escalations, appointments, outreach history, conversations, approvals. | | Audit log | Generated | Append-only; never purged. | ## Redaction [Section titled “Redaction”](#redaction) Personal data in conversation records and in what is shown to the assistant is redacted according to the institution’s setting: **Full** (the default), **Partial** or **Off**. See [Data policy](/administration/data-policy/). ## Retention [Section titled “Retention”](#retention) Conversations and abandoned drafts are purged nightly after the windows the institution sets (by default one year for conversations and 30 days for drafts). Staged rows from nightly imports are kept for 30 days. The audit log is not subject to retention. ## Individuals’ requests [Section titled “Individuals’ requests”](#individuals-requests) Any signed-in user can download the data Unifuse holds about them and request erasure from their profile. Institutions review and carry out erasure requests, with a dry run first and a 30-day due date. See [Privacy requests](/administration/privacy-requests/). ## When an institution leaves [Section titled “When an institution leaves”](#when-an-institution-leaves) Unifuse deactivates the institution, which stops sign-ins; exports its audit log on request; then purges all of its data and files after a dry run. Database backups age out after seven days and old file versions after 30, so the data is fully gone within 30 days of the purge. The audit log and a placeholder record of the institution are kept. ## Subprocessors [Section titled “Subprocessors”](#subprocessors) The current list of subprocessors is on the [Trust Center](https://trust.unifuse.ai/). ## Related [Section titled “Related”](#related) * [Security overview](/trust/security/) # Security overview > How Unifuse protects institutional data: single sign-on only, tenant isolation enforced in the database, encryption, an append-only audit log, governed AI actions, and where to find the SOC 2 and policy documents. This page summarises the security controls a prospective customer or IT reviewer will ask about. Policies, the SOC 2 report and vendor documentation are on the [Unifuse Trust Center](https://trust.unifuse.ai/). ## Identity [Section titled “Identity”](#identity) * Users sign in only through their institution’s identity provider over OIDC or SAML. Unifuse holds no passwords. See [Single sign-on](/administration/single-sign-on/). * Accounts are provisioned and deactivated by the identity provider through SCIM, and a deactivated account is refused at sign-in even if the identity provider still accepts it. * Institutions set an idle timeout and a maximum session length, and can end any user’s sessions at once. See [Session policy](/administration/session-policy/). ## Tenant isolation [Section titled “Tenant isolation”](#tenant-isolation) Every institution’s data is isolated at the database layer: the database itself enforces that a request scoped to one institution can read or change only that institution’s rows. A request with no institution scope sees nothing. This is not left to application code. ## Permissions [Section titled “Permissions”](#permissions) Every screen and every API call is gated by a permission on the user’s role, and the server enforces it on each request. Institutions edit the permission matrix themselves; see [Roles](/administration/roles/). ## Encryption [Section titled “Encryption”](#encryption) Data is encrypted in transit and at rest. Credentials for connected systems are stored encrypted and separately from the rest of a source’s configuration, and are never shown back after entry. ## Audit log [Section titled “Audit log”](#audit-log) Sign-ins, failed sign-ins, session events, administration changes, provisioning, data access, unmasking of personal data, messages to students and every AI tool call are written to an append-only audit log that is never purged. Institutions can read and export it. See [Audit log](/administration/audit-log/). ## Governed AI [Section titled “Governed AI”](#governed-ai) The assistant answers only from the institution’s own sources and says when it cannot. Any action it proposes runs under a trust tier that decides who must approve it, with the exact parameters shown before anyone says yes. Some actions are never available to it. An administrator can pause every agent with one switch. See [Approvals and trust tiers](/ai-assistant/approvals/). ## Student contact [Section titled “Student contact”](#student-contact) Every message to a student passes a contact gate: consent, a per-student message budget, quiet hours, and review where the institution requires it. Opt-outs are honoured on every channel and can never be overridden. See [Contact policy](/administration/contact-policy/). ## Hosting [Section titled “Hosting”](#hosting) Unifuse runs on Google Cloud in the United States. Service status and incident history are published on the [status page](https://status.unifuse.ai/). ## Reporting a vulnerability [Section titled “Reporting a vulnerability”](#reporting-a-vulnerability) Email . The Trust Center lists the current disclosure policy. ## Related [Section titled “Related”](#related) * [Data handling](/trust/data-handling/) * [Accessibility](/trust/accessibility/) # Status and updates > Where to see Unifuse service status and incident history, how releases are announced, and how to read this documentation with an AI assistant. ## Service status [Section titled “Service status”](#service-status) Live status and incident history are at [status.unifuse.ai](https://status.unifuse.ai/). Subscribe there for notifications. ## Releases [Section titled “Releases”](#releases) Every production release is described on the [changelog](https://changelog.unifuse.ai/), newest first, with entries tagged Added, Changed, Fixed, Security and Removed. The same notes appear inside the product under **What’s new** in the user menu, which shows the version you are on. ## This documentation [Section titled “This documentation”](#this-documentation) This site describes the production product. Pages are updated with the release that changes them. Each page shows when it was last updated. ## Reading the documentation with an AI assistant [Section titled “Reading the documentation with an AI assistant”](#reading-the-documentation-with-an-ai-assistant) The site is published for assistants as well as people: * Append `.md` to any page address to get that page as plain Markdown, for example `https://docs.unifuse.ai/administration/users.md`. * [`/llms.txt`](/llms.txt) is an index of the whole site with a one-line description of each page. * [`/llms-full.txt`](/llms-full.txt) is every page in one file, and [`/llms-small.txt`](/llms-small.txt) is the same with non-essential content removed. These files are generated from the same sources as the pages, so they are never out of step.