OnboardConnect

1. What is OnboardConnect?

OnboardConnect is a cloud-based platform that automates the full student account lifecycle for higher education, triggered by Slate CRM imports. It provisions and maintains accounts across three identity platforms and writes results back to your Student Information System (SIS) — eliminating manual work and reducing provisioning lag from days to minutes.

Identity platforms (directory targets)

A single workflow can target any combination of three directories:

• On-Prem Active Directory — via the on-prem OnboardConnect Agent over LDAP.
• Microsoft Entra ID (Azure AD) — via the Microsoft Graph API directly from the cloud, no agent required.
• Google Workspace for Education — via the Google Admin SDK, connected with a service account that has domain-wide delegation.

SIS writeback

OnboardConnect reads from and writes back to your SIS so the directory and the system of record stay aligned. Supported systems are Ellucian Ethos (Banner and Colleague), Oracle PeopleSoft, and Workday Student. SIS access runs through the on-prem Agent as a local SIS profile, so your SIS credentials stay on campus — a "SIS" connection in the portal simply points at the agent, the profile, and the vendor.

How it works

1. Data arrives — via either Slate connection type: Query Web Services or Source Format API.
2. The workflow runs — your visual workflow evaluates and shapes each record, then executes its ordered steps against AD, Entra, Google Workspace, the SIS, files, and notification channels.
3. The right surface executes — on-prem AD and SIS actions run through the OnboardConnect Agent inside your network; Entra runs through Microsoft Graph; Google Workspace runs through the Admin SDK.
4. Results are logged — every action is recorded in the Audit Log with actor, timestamp, and outcome, and the full run history is retained with a live run view.

The visual workflow builder

The core of OnboardConnect is a drag-and-drop workflow builder. Steps are ordered and branchable with On Success / On Failure lanes, each step has per-step field mapping, and rows can be filtered and transformed between steps. Workflows support continue-on-error, chunked processing of large imports, and full run history with a live run view. See the complete Workflow Action Catalog for every available step.

Key capabilities

2. Your 90-Day Trial

Every new institution starts with a full 90-day trial. During the trial:

• All features are fully unlocked — no functionality is restricted.
• There are no student creation limits. You can provision as many accounts as you need to test the full workflow.
• No credit card or purchase order is required to start.
• A yellow banner appears in the portal showing how many days remain.

3. Initial Setup

After your account is provisioned by Zentrosoft, you will receive a login invitation email. Complete setup in this order:

3.1 Sign in for the first time

1. Click the link in your invitation email.
2. Set your password and complete your profile.
3. Sign in at your institution's OnboardConnect portal URL (e.g., app.onboardconnectapp.com).

3.2 Configure your AD connection

Go to Connections and add your Active Directory or Azure AD connection. For on-premise AD, install the OnboardConnect Agent on a server inside your network first — see On-Premise Agents. For Azure AD / Entra ID, no agent is required — provisioning uses the Microsoft Graph API directly.

3.3 Set up your data source

Connect at least one Slate data source:

• Slate Query Web Services — OnboardConnect polls Slate on a schedule. See Slate CRM.
• Slate Source Format API — receives data via Slate's Source Format API. See Slate CRM.

3.4 Create your first Workflow

Go to Workflows and create a rule that maps incoming student data to a provisioning action. See Workflows for details.

3.5 Configure Provisioning Settings

Go to Provisioning Settings and configure how accounts are built: set your username format template, password policy, OU placement rules, and group membership rules. See Provisioning Settings for details.

3.6 Configure Record Management

If your team needs to look up student accounts in the portal, go to Record Management (labeled Search Settings in the sidebar under some configurations) and mark at least one Azure AD or On-Prem Agent connection as Active, then configure which attributes are searchable and which connection handles each user action. See Search Settings for details.

3.7 Run a test

Trigger a manual run with a test record to verify the end-to-end flow before enabling automatic polling. See Testing a workflow for details.

4. Users & Roles

OnboardConnect uses role-based access control (RBAC). Each user is assigned a role that determines which portal sections and actions they can access.

Manage users from Settings → Users & Roles. See Users & Roles settings.

5. Dashboard

The Dashboard gives you a real-time snapshot of your provisioning environment.

KPI cards

Each card shows a delta indicator (arrow and count) comparing the current value to the previous period. The comparison row is hidden when the delta is zero — it only appears when there is a meaningful change.

Recent activity

The activity feed shows the last 10 provisioning events with student name, action taken, and result. Click any row to open the full Audit Log entry.

Job queue chart

A bar chart showing daily job volume (created, updated, disabled) for the past 14 days. Useful for identifying unusual spikes or drops in provisioning activity.

Navigating lists

Every paginated table in the portal — Students, Workflows (runs and workflow lists), Connections, Credentials, Agents, Provisioning Rules, Scheduled Deletions, Audit Log, Reports, Email Templates, and Users & Roles — uses the same pagination footer beneath the table card:

• Left: Showing X–Y of Z records.
• Center: Rows per page selector with 25, 50, or 100 options (default 25).
• Right: Previous / current page / total / Next controls.

The previous "Load more" and "Show more" buttons have been retired across the portal. All list pages behave the same way.

6. Directory Search

Directory Search queries the connected directory live for user accounts. It is the searchable view IT staff use to look up student records in the connections you have marked as Active.

6.1 Search results

Use the search bar and the searchable attributes configured in Search Settings to find users. The search spans both the connection's configured search OU and its Disable OU (where deactivated accounts are moved), so disabled accounts still appear in results.

Each result row shows a status badge — green Active or red Disabled — so you can tell at a glance whether an account is enabled.

6.2 Student detail

Click any student row to open their detail view. The detail page contains three tabs:

• Overview — sections and fields defined in Search Settings → Detail Views → Full Detail Page. What appears here is fully administrator-configurable. If no sections have been configured, a prompt directs you to Record Management to set them up.
• AD Groups — Active Directory group memberships recorded for this student.
• Provisioning History — every provisioning action taken on this student with timestamps and outcomes.

6.3 Manual actions

From the student detail page, authorized users can trigger manual actions using the action buttons displayed at the top of the record. Buttons appear only for actions that the configured connection supports:

The button order in the UI is: Security Groups, Distribution Lists, Reset Password, then Deactivate/Activate.

7. Workflows

Workflows are the heart of OnboardConnect. Each workflow defines a set of conditions to match against incoming student data and an action to take when those conditions are met.

7.1 How workflows work

When a new student record arrives (via Slate Query Web Services or Source Format API), the system evaluates each active workflow in order until one matches. The matching workflow's action is queued as a provisioning job.

7.2 Creating a workflow

1. Go to Workflows and click New Workflow.
2. Give the workflow a descriptive name (e.g., "New undergrad — create AD account").
3. Set the trigger: enrollment event type (new admit, re-enroll, withdrawal, graduation).
4. Add conditions to filter which students match (e.g., Program = "Undergraduate", Campus = "Main").
5. Choose the action: Create, Update, Disable, or Delete.
6. For Create actions, confirm your Provisioning Settings are configured — username format, OU placement, and group assignments are defined there. See Provisioning Settings.
7. Toggle Active and save.

7.3 Conditions

Each condition is a field/operator/value triple. Supported fields include:

Combine multiple conditions with AND (all must match) or OR (any must match).

7.4 Actions

Utility steps (category "Others")

These step types do not touch Active Directory. They shape, route, or report on the rows flowing between other steps, and the columns they add become available to every later step.

On-Prem Create — Initial Password (optional)

The On-Prem Create step can set an initial password in the same operation that creates the account. When enabled it lets you:

• Choose the password source — Generate from Password Policy (uses your Provisioning Settings → Password policy) or Static (one fixed value).
• Force change at next sign-in.
• Enable the account on creation.
• Expose the value as the Generated Password output column, for use by a later welcome-email or writeback step.

On-Prem Create — userPrincipalName

The userPrincipalName is generated as sAMAccountName@<domain>, where the domain comes from Provisioning Settings → Username Format. It is kept separate from the email address (mail), so the two can differ.

Custom attributes (Create & Update)

On-Prem Create and Update steps can map extra AD attributes — for example extensionAttribute1 or studentid — each sourced from a row column or a static value.

7.4a Workflow Action Catalog

A workflow is built from steps. Each step belongs to a group below and is added from the step palette in the builder. Steps are ordered and branchable (On Success / On Failure), and every step exposes per-step field mapping so you control exactly which row column feeds which target attribute. The catalog is grouped in the order the palette presents it.

Slate

On-Prem Active Directory

Executed by the on-prem OnboardConnect Agent over LDAP.

Microsoft Entra

Executed directly through the Microsoft Graph API — no agent required.

Google Workspace

Executed through the Google Admin SDK using a service account with domain-wide delegation.

Files

Executed by the on-prem Agent against a network path the agent service account can reach.

Slate file transfer steps (Download / Upload)

The two Slate file transfer steps move whole files between Slate and your on-prem Agent machine without standing up an SFTP server. Transfers run over authenticated HTTPS and are built to handle large binaries — PDFs, scanned documents, and other multi-MB files. They sit alongside Query Service Read and Source Format Write in the Slate-triggered workflow builder.

Slate File Download

Pulls a file from Slate and writes it to a folder on the Agent host machine — for example, to land a document export where another campus process can pick it up. Configuration fields:

Slate File Upload

Takes a file from the Agent host machine and uploads it into Slate through a Source Format. Configuration fields:

Prerequisites for Slate file transfer

• On-prem Agent outbound HTTPS. The Agent machine must be able to reach Slate and the OnboardConnect staging endpoint over outbound HTTPS — that is the only network path the bytes use.
• Slate Source Format (upload). Slate File Upload requires a configured Slate Source Format connection to receive the file. See Slate CRM.
• Authenticated Slate file URL or query (download). Slate File Download requires a Slate Query Web Services connection plus either the authenticated file URL or the query GUID that resolves to the file.
• Agent file access. The Agent service account needs read access to the upload source path and write access to the download destination folder. Verify both with the Service Account Access Check.

Student Information System

Executed by the on-prem Agent against the SIS profile referenced by a "SIS" connection (Ellucian Ethos / Banner / Colleague, Oracle PeopleSoft, or Workday Student).

Flow & Logic

Notifications

SMS Notify — the two modes

The SMS step runs through a Twilio connection in one of two modes:

• Single alert — one message sent to a single fixed number you enter on the step. Use it to notify an administrator or on-call inbox that a run finished (the message supports the same {tokens} as Chat).
• Per-row — one text per row, sent to the phone number in a row column you map (for example a mobile field). Use it to text every newly provisioned student a credential or welcome message.

7.5 Username format

Username format is now configured in Provisioning Settings → Username tab. See Provisioning Settings.

7.6 Reordering workflows

Drag and drop workflow rows to change evaluation order. Changes are saved immediately.

7.7 Trigger on Provisioning Event

Workflows with this toggle enabled run automatically after a student account is successfully provisioned. Use this to chain follow-up actions — for example, sending a welcome email immediately after account creation — without requiring a separate data file or schedule.

7.8 Testing a workflow

Use the Test button on any workflow to run it against a sample student record without executing any real actions. The test result shows which step would be taken and why.

7.9 Running a workflow & live progress

You can run a workflow on demand from the editor with the Run button in the top-right, next to Save. While a run is in progress the editor is locked — no edits are possible — until the run finishes.

As the run executes, each step shows live status (running → completed or failed) together with its result detail, for example "Created 2 AD accounts via on-prem agent".

The connectors between steps visualize the data handoff:

• The record count flowing from one step to the next.
• A live in-transit animation while data moves between steps.
• Click a connector to see the actual rows passed to the next step as a table (password fields are masked). When no run data exists yet, the connector shows the field names instead.
• Connectors are color-coded by the upstream step's action.

7.10 Filtering & pinning the workflows list

The Workflows list has a filter toolbar above the table:

• Search — matches workflow name or description.
• Status — Active or Inactive.
• Group — by the workflow's color group.
• Schedule — Scheduled or Manual.
• Pinned only — a toggle that limits the list to pinned workflows.

Use the pin icon on any row to pin a workflow. Pinned workflows sort to the top of the list and can be isolated with the Pinned only toggle.

8. Connections

Connections define the external systems OnboardConnect communicates with. They are added from Connections → Add Connection. The available connection types are:

8.1 Slate connection types

Two Slate connection types are available. Configure at least one from Connections → Add Connection:

• Query Web Services: OnboardConnect polls Slate's Query Web Services API on a configurable schedule. Provide the Slate instance URL, query key, and credentials. Records returned by the query are evaluated against your Provisioning Settings and Workflows.
• Source Format API: Slate sends data to OnboardConnect via the Source Format API. Configure the endpoint in Slate and enter the shared secret in OnboardConnect.

8.2 Azure AD / Microsoft Entra ID connection

Connect to Azure AD via the Microsoft Graph API. Required fields: Tenant ID, Client ID, Client Secret (from an Azure app registration with User.ReadWrite.All and GroupMember.ReadWrite.All permissions).

Connections can be marked as Active Connection — when enabled, this connection becomes available for directory search and user actions in Search Settings. Active connections display a teal "Active" badge on the connection card.

8.3 On-Prem Agent connection

Configure the on-premise LDAP connection by providing: display name, LDAP server host/port, bind DN and password, base DN, and optionally a Default OU and Disabled OU. The Agent must be installed first — see On-Premise Agents.

Like Azure AD, On-Prem Agent connections can be marked as Active Connection to enable directory search and user actions.

8.4 Active Connection flag

The Active Connection toggle appears on Azure AD and On-Prem Agent connections. When enabled:

• The connection's AD attributes become available for selection in Search Settings
• The connection can be assigned as the handler for Search, Activate/Deactivate, Password Reset, Security Groups, and Distribution Lists actions in Search Settings → Record Management → Active Connections

Multiple connections can handle Search simultaneously. All other actions (Activate/Deactivate, Password Reset, Security Groups, Distribution Lists) are exclusive — only one connection can be assigned each action at a time.

8.5 Connection tile layout

Every connection on the Connections page renders as a tile with the same structure, regardless of type. From top to bottom:

• Connection name — the primary heading, bold and dark. A thin colored stripe runs down the left edge of the card to mark the type without dominating the layout.
• Type label — sits subtly in the top-right corner with a small tinted icon: Slate Query Service, Slate Source Format, Azure AD, or On-Prem Agent.
• Health line — a colored status dot followed by Healthy, Connection failed, or Not tested yet, with a Tested 2m ago timestamp when a recent test exists.
• Chip row — small chips for Enabled or Disabled, capability flags such as Record Management (shown when enabled on Azure AD or On-Prem Agent connections), and provider hints.
• Connection ID — displayed on every tile (previously only on On-Prem Agent) with a copy-to-clipboard button.
• Footer actions — a primary Test button and a secondary Edit button side by side. The kebab menu (⋮) on the right contains Enable / Disable and Delete.

Click Test on any tile to run an immediate health check; the health line and timestamp update in place.

8.6 Google Workspace connection

Connect to Google Workspace for Education through the Google Admin SDK. OnboardConnect authenticates as a service account with domain-wide delegation, so no individual admin password is stored.

1. In the Google Admin console, create (or select) a service account and enable domain-wide delegation, authorizing the Admin SDK scopes for users and groups.
2. In OnboardConnect, go to Connections → Add Connection → Google Workspace.
3. Provide the service account JSON key, the admin email to impersonate (a Workspace super-admin), and your primary domain.
4. Click Test to verify the Admin SDK responds, then save.

Once connected, Google Workspace steps (Create, Update, Activate, Suspend, Set Password, Groups) become available in the workflow builder.

8.7 SIS connection

A SIS connection lets workflows read from and write back to your Student Information System. To keep SIS credentials on campus, the connection does not hold them — instead it points at an on-prem Agent and a SIS profile defined on that agent.

1. On the on-prem Agent, configure a SIS profile with the vendor (Ellucian Ethos for Banner/Colleague, Oracle PeopleSoft, or Workday Student) and its local credentials.
2. In OnboardConnect, go to Connections → Add Connection → SIS.
3. Select the Agent, choose the SIS profile exposed by that agent, and confirm the vendor.
4. Click Test — the agent validates it can reach the SIS using the local profile — then save.

8.8 Notification connections (SMTP, Twilio SMS)

Notification connections back the workflow Notifications steps. They are added the same way as other connections and selected on the relevant step.

• SMTP — backs the workflow Email step. Provide host, port, username/password, and the from address. Supports both single run-summary emails and per-row emails.
• Twilio SMS — backs the workflow SMS step. Provide your Twilio Account SID, Auth Token, and a sending number (or Messaging Service SID). One Twilio connection drives both SMS modes — a single alert to one number, or a per-row text to each row's mapped phone field (see Workflow Action Catalog → SMS Notify).

9. Search Settings

Search Settings lets administrators define the entire directory search experience for their institution. Changes here affect what IT staff see when searching for students and which AD connections handle user actions.

9.1 Active Connections tab

Lists all Azure AD and On-Prem Agent connections that have the Active Connection flag enabled. Select a connection from the left panel to configure its allowed actions in the right panel. The page automatically selects the first connection that already has actions configured when it loads.

For each connection, check the actions it should handle:

• Search — this connection's directory is queried when IT staff search for students. Multiple connections can handle Search simultaneously.
• Activate / Deactivate — this connection executes account activation and deactivation requests. Only one connection can be assigned this action at a time.
• Password Reset — this connection executes password reset requests. Only one connection can be assigned this action at a time.
• Security Groups — this connection is used to view and sync security group memberships. Only one connection can be assigned this action at a time.
• Distribution Lists — this connection is used to view distribution list memberships. Only one connection can be assigned this action at a time.

The Searchable Attributes, List Columns, and Detail Views tabs are locked until at least one connection has Search enabled. If no connections appear in this tab, go to Connections and enable the Active Connection toggle on at least one Azure AD or On-Prem Agent connection.

9.2 Searchable Attributes tab

Lists all available AD attributes from active connections, grouped by connection name. Check the attributes IT staff should be able to search by. For each checked attribute, enter a user-friendly label (e.g., "Display Name" instead of "displayName").

Azure AD provides attributes including: displayName, mail, userPrincipalName, sAMAccountName, givenName, surname, department, title, and more. On-Prem LDAP provides attributes including: cn, sAMAccountName, mail, givenName, sn, department, title, distinguishedName, and more.

If an attribute your institution uses isn't surfaced by the agent's schema sync, click Add Attribute (next to Sync Agent Attributes) to add it manually. The dialog asks for the LDAP attribute name, a display label, and a type. Once added, the attribute becomes selectable across Searchable Attributes, List Columns, and Detail Views.

9.3 List Columns tab

Defines which attributes appear as columns in the student search results list. Use the Add Column picker to add attributes from your checked searchable attributes. For each column:

• Reorder with the up/down arrows
• Set the display type: Text, Badge, or Date
• Toggle Sortable to allow sorting by this column
• Set column width: Small, Medium, Large, or Auto
• Remove to hide from results

9.4 Detail Views tab

Configures what IT staff see when they click a student in the search results:

• Side Panel — a flat list of attributes shown in the quick-view panel. Add attributes in the order you want them displayed.
• Full Detail Page — named sections (e.g., "Account Info", "Contact Details") each containing a list of attributes. Create multiple sections to organize related attributes together.

Click Save Settings to apply all changes across all four tabs.

10. Provisioning Settings

Provisioning Settings defines how AD accounts are built — username format, password policy, OU placement, and group membership. These settings apply globally across all provisioning actions.

10.1 Username tab

Define the template used to generate usernames for new accounts. Use {field_name} tokens to reference student data fields from your Slate connection:

{first_name[0]}{last_name}          → jsmith
{first_name}.{last_name}            → john.smith
{first_name}.{last_name}{grad_year} → john.smith25
{student_id}                        → 1234567

The [0] syntax extracts just the first character of a field. A live preview shows how the template renders using sample data.

Additional options:

• Transform — Lowercase, Uppercase, or None
• Email domain — appended to create the UPN (e.g., @university.edu)
• Collision strategy — how to handle duplicate usernames: append a counter (jsmith2, jsmith3) or append a random suffix

10.2 Password tab

Configure the initial password policy for newly created accounts:

• Type — Random (secure generated), Student ID (uses the student's ID number), or Fixed (a specific value you define)
• Minimum length — minimum character count
• Complexity — require uppercase, lowercase, numbers, and/or symbols
• Require password change on first logon — forces the student to set a new password when they first sign in

A 4-segment strength indicator reflects the current policy's overall strength.

10.3 OU tab

Define where new accounts are placed in the Active Directory tree:

• Default OU — the fallback OU for all accounts that don't match a conditional rule (e.g., OU=Students,DC=university,DC=edu)
• Conditional rules — ordered rules evaluated top-to-bottom. Each rule has one or more field conditions and a target OU. The first matching rule wins. Example: if Program equals "Nursing" → OU=Nursing,OU=Students,DC=university,DC=edu

Rules support these condition operators: equals, not equals, contains, starts with, ends with, is in list, is not in list, is empty, is not empty.

10.4 Security Groups tab

Define which security groups a student is added to when their account is provisioned. Rules are additive — a student can match multiple rules and be added to all matching groups.

Each rule has: one or more field conditions, and one or more group Distinguished Names (DNs) to add the account to. To always add all students to a group (unconditionally), create a rule with no conditions checked.

10.5 Distribution Lists tab

Same structure as Security Groups, but for mail-enabled distribution lists. Rules are additive and evaluated independently from security group rules.

Click Save Settings at the top of the page to apply all tab changes.

11. Audit Log

The Audit Log is an immutable record of every provisioning action and administrative change in your OnboardConnect account.

11.1 What is logged

• Every student provisioning action (create, update, disable, delete) with outcome
• Manual actions triggered by portal users
• Workflow changes (created, modified, deleted, reordered)
• Connection configuration changes
• User invitations, role changes, and removals
• Settings changes
• Agent connection and disconnection events

11.2 Reading log entries

Each entry shows:

11.3 Filtering and searching

Filter the audit log by date range, actor, event type, student name/ID, and result (success/failure). Export filtered results to CSV for compliance reporting.

12. Reports

The Reports section provides pre-built reports and lets you save custom filtered views.

12.1 Built-in reports

12.2 Saved reports

Apply filters to any report and click Save Report to save your filter configuration. Saved reports appear in the Saved tab and can be re-run at any time or scheduled for periodic email delivery.

12.3 Exporting

Every report can be exported as CSV. Click Export CSV at the top of any report view.

13. Alerts

The Alerts module sends proactive email notifications to designated portal users when critical system events occur. Navigate to Alerts in the left sidebar under the Reporting group.

13.1 Alert types

13.2 Enabling and disabling alert types

Each alert type is toggled independently using the on/off switch in the Alerts page. All three alerts are enabled by default when preferences are first saved.

13.3 Configuring recipients

By default, when no specific recipients are selected, all active portal users receive alert emails. To restrict notifications to specific team members:

1. Go to Alerts in the sidebar.
2. Scroll to the Alert Recipients section.
3. Check the boxes next to the users who should receive alerts.
4. Click Save Preferences.

13.4 Permissions

Viewing the Alerts page requires the alerts.view permission. Saving changes requires alerts.configure. These permissions can be assigned to custom roles from Settings → Users & Roles → Roles.

14. Usage

The Usage section shows your annual student account creation consumption against your plan limit.

Reading the usage dashboard

If you are approaching your limit, contact solutions@zentrosoft.com to discuss increasing your limit or upgrading your plan.

15. Settings — User Provision

Configure global provisioning behavior that applies to all workflows.

15.1 Disable delay

When a student withdrawal is received, you can configure a grace period (in days) before the account is actually disabled. This prevents accidental lockouts from brief administrative enrollment gaps.

15.2 Notifications

Configure email notifications for provisioning events:

• New account created — send welcome email to student
• Account disabled — notify student and/or IT staff
• Provisioning errors — alert specific IT staff addresses

16. Settings — Users & Roles

16.1 Inviting users

1. Go to Settings → Users & Roles.
2. Click Invite User.
3. Enter the user's work email and select their role.
4. Click Send Invite. The user receives an email with a setup link valid for 48 hours.

16.2 Managing existing users

From the user list, you can:

• Change a user's role
• Suspend a user (blocks login, preserves account)
• Reactivate a suspended user
• Remove a user entirely
• Resend an invitation that hasn't been accepted

16.3 Custom roles

In addition to the built-in roles, Owners can create custom roles with fine-grained permission sets. Click New Role, name it, and toggle individual permissions on or off.

17. Settings — SSO

OnboardConnect supports OpenID Connect (OIDC) single sign-on for staff portal logins. SSO is configured per institution and allows your team to authenticate using your existing identity provider (Okta, Azure AD / Entra ID, Auth0, Keycloak, or any other OIDC-compliant IdP).

17.1 Configure OIDC SSO

1. Go to Settings → SSO.
2. In the OIDC Configuration section, enter the Discovery URL — this is the /.well-known/openid-configuration endpoint from your identity provider (e.g., https://your-idp.example.com/.well-known/openid-configuration).
3. Enter the Client ID assigned to OnboardConnect in your IdP application.
4. Enter the Client Secret from your IdP application.
5. In your identity provider, register the Callback / Redirect URI shown in the IdP Setup section of the SSO settings page.
6. Click Save OIDC Settings.
7. Click Test SSO Login to verify the configuration before enabling.
8. Toggle Enable / Disable to activate SSO.

17.2 SSO Login URL

After saving your OIDC settings, the IdP Setup section of the SSO page displays an SSO Login URL field. This is the direct URL that initiates the SSO login flow for your institution.

• Click Copy URL to copy the full URL to the clipboard.
• Share this URL with your team members so they can sign in via SSO. Bookmarking or linking to it from your institution's intranet or help desk portal is recommended.

18. Settings — Developer

18.1 API keys

Generate API keys to authenticate requests to the OnboardConnect REST API from your own scripts or systems.

1. Go to Settings → Developer.
2. Click New API Key, name it descriptively (e.g., "Banner integration").
3. Copy the key immediately — it will not be shown again.

18.2 Webhooks

Configure an HTTPS endpoint to receive real-time event notifications. OnboardConnect sends a POST request with a JSON payload for every provisioning event.

Available webhook events:

• student.provisioned — new account created
• student.updated — account attributes updated
• student.disabled — account disabled
• student.deleted — account removed
• job.failed — provisioning job failed
• agent.disconnected — on-premise Agent went offline

Payloads are signed with an HMAC-SHA256 signature using your webhook secret. Verify the X-OC-Signature header on every received request.

18.3 Webhook signature verification

// Node.js example
const crypto = require('crypto');
const signature = req.headers['x-oc-signature'];
const body = req.rawBody; // raw JSON string
const expected = crypto
  .createHmac('sha256', process.env.OC_WEBHOOK_SECRET)
  .update(body)
  .digest('hex');
if (signature !== expected) return res.status(401).end();

19. Integration — Active Directory / LDAP

OnboardConnect connects to your on-premise AD through the OnboardConnect Agent — a lightweight service that runs inside your network and receives encrypted provisioning instructions from the cloud.

19.1 Install the Agent

1. On the target Windows Server machine, open PowerShell as Administrator and run npm install -g onboardconnect-agent.
2. In the portal, go to Connections → Add Connection → On-Prem Agent and click Generate Setup Token. Copy the one-time token (valid 30 minutes).
3. Back in PowerShell, run oc-agent setup and paste the setup token when prompted. The wizard installs the Windows service and starts the agent.
4. Open a browser on the agent host machine and navigate to http://localhost:7432. Log in using the agent token shown in the PowerShell console output.
5. Go to the Setup tab in the Agent Management UI and configure your LDAP settings (server host/port, bind DN, base DN).
6. Return to the portal under Connections and confirm the agent connection card shows Connected.

19.2 Agent requirements

19.3 High availability

Install the Agent on two servers for redundancy. OnboardConnect automatically load-balances and fails over between healthy agents. Both agents must use the same tenant token.

19.4 AD service account permissions

The Agent runs as a Windows service under a dedicated AD service account. Grant the account Create, Delete, Modify permissions on the target OUs, and Reset Password rights if you use OnboardConnect password resets.

19.5 LDAP authentication modes

On the Setup tab of the Agent Management UI, the LDAP configuration offers two Authentication Modes:

20. Integration — Slate CRM

OnboardConnect integrates with Technolutions Slate through two connection types. Choose whichever your institution's Slate configuration supports.

20.1 Query Web Services

OnboardConnect polls Slate's Query Web Services API on a schedule and retrieves student records directly.

1. Go to Connections → Add Connection → Slate Query Web Services.
2. Enter your Slate instance URL (e.g., https://apply.university.edu).
3. Enter the Query Key from your Slate Query Web Services configuration.
4. Enter the Slate credentials (username/password with Query Web Services access).
5. Set the polling schedule.
6. Click Test Connection to verify access and preview returned records.
7. Toggle Active to enable scheduled polling.

20.2 Source Format API

Slate pushes data to OnboardConnect via the Source Format API on your defined schedule or trigger.

1. Go to Connections → Add Connection → Slate Source Format API.
2. Copy the OnboardConnect Source Format endpoint URL and shared secret.
3. In Slate, configure the Source Format to push to the OnboardConnect endpoint URL using the shared secret for signature verification.
4. Map the Source Format fields to OnboardConnect student fields in the connection form.
5. Click Save. OnboardConnect will begin accepting data as soon as Slate pushes it.

20.3 Field mappings

Each Slate connection type includes a field mapping configuration. Map Slate field names to the standard OnboardConnect student fields (first_name, last_name, student_id, email, enrollment_status, program, campus, etc.). You can also map custom Slate fields to use them in Provisioning Settings conditional rules.

21. On-Premise Agents

The OnboardConnect Agent is a lightweight Windows service that bridges the cloud platform with your on-premise Active Directory environment.

21.1 Viewing agent status

There are two places to check agent status:

• Portal (cloud view): Go to Settings → Agents. Each agent card shows DB status and last heartbeat. Click Check Status to see the live relay connection, including whether the agent is connected, paused, or offline, plus actionable advice.
• Agent Management UI (local view): Open http://localhost:7432 on the agent host machine. This shows real-time CPU/memory, uptime, pending commands, LDAP settings, and service controls (Pause, Resume, Reconnect, Stop). Use the token shown in the agent console output to log in.

If an agent stops sending heartbeats for more than 15 minutes, the system marks it stale and sends an Agent Goes Offline email to the configured alert recipients (see Alerts). The email identifies the affected agent by its friendly name — the same name shown on the Agents list — so administrators can immediately tell which Windows Server stopped reporting without having to look up an internal identifier.

21.2 Pausing and resuming the agent

You can temporarily pause the agent from the Agent Management UI at http://localhost:7432. While paused, the agent stays connected but does not execute any commands — they remain queued and will run when you resume. The portal will show the agent as "Connected — paused" and will display a clear error if a workflow attempts to dispatch a command while the agent is paused.

21.3 Agent logs

On the agent host machine, logs are written to %USERPROFILE%\.oc-agent\logs\. Log rotation happens daily with a 30-day retention. You can also view recent requests directly in the Agent Management UI under the Requests tab.

21.4 Updating the agent

On startup, the agent queries the npm registry to check whether a newer version of onboardconnect-agent is available. If a newer version exists, the agent logs a warning and prints an upgrade banner to the console and log file — it does not download or restart automatically.

To update the agent to the latest version:

1. Stop the Windows service from the Agent Management UI (Status tab → Stop) or from the Windows Services console.
2. Open PowerShell as Administrator and run npm install -g onboardconnect-agent@latest.
3. Start the Windows service again from the Services console or run oc-agent start.

21.5 Revoking an agent

To decommission an agent, click Revoke from the agent list in the portal. The agent will immediately stop accepting provisioning jobs. Then uninstall the agent from the host machine (see 21.6).

21.6 Uninstalling the agent

To cleanly remove the agent from a server:

1. Open PowerShell as Administrator on the agent host machine.
2. Run oc-agent uninstall and type YES when prompted.
3. The wizard stops the Windows service, removes the service registration, and deletes the config directory (C:\ProgramData\OnboardConnect\). You can optionally also remove log files and the npm package.
4. Return to the portal (Settings → Agents) and click Revoke on the agent card to clean up the cloud registration.

Alternatively, run the included scripts\uninstall.ps1 script directly from the agent installation directory. It accepts -KeepLogs and -KeepPackage flags.

21.7 Allowed Command Types

The Settings tab at http://localhost:7432 lets administrators control exactly which operations this agent instance can execute. Changes to the command allowlist take effect after restarting the Windows service.

Commands are organized into five groups:

The Group Membership commands let the agent apply security-group and distribution-list memberships — both those assigned by workflows and those triggered manually from Directory Search. Like the others, each is an individual toggle and is enabled by default.

Each command can be individually enabled or disabled using a toggle. Each group also has an Enable all / Disable all shortcut. Disabling a command type causes the agent to reject any incoming command of that type before any AD action is taken, and returns a clear error message to the portal. By default all non-destructive commands are enabled; Delete User is disabled by default.

After adjusting the allowlist, click Save Command Filter, then restart the service from the Status tab for changes to take effect.

21.8 Command History

The Requests tab at http://localhost:7432 shows a real-time log of every command the agent has received during the current session. Columns:

History is kept in memory for the current session only and clears when the agent service restarts. The list polls for new entries automatically every 30 seconds, and also refreshes immediately whenever a new status event arrives.

21.9 Service Account Access Check

The Settings tab includes an Access Check tool that verifies the Windows service account has all required permissions before running provisioning jobs. Click Run Access Check to test the following:

The check also displays the Windows account name under which the agent service is currently running. Run this check after initial setup or after changing service account credentials to confirm all permissions are in place before the first live provisioning job.

21.10 Signing in / session

When you open the Agent Management UI at http://localhost:7432, it validates the saved access token against the running agent. If the stored token is invalid, expired, or revoked — the agent answers with a 401 — the UI automatically returns you to the login screen so you can paste a fresh token.

A token entered for an agent that is merely unreachable (for example, the service is stopped) is not discarded; the UI keeps it and simply reports the agent as offline. Get the current token from the agent console output, as described in 21.1.

22. Plans & Limits

All plans include unlimited workflow rules, connections, audit log access, reports, API calls, and portal users. The only variable is the annual student account creation limit.

To upgrade your plan or increase your limit mid-year, contact solutions@zentrosoft.com.

23. API & Webhooks

OnboardConnect exposes a REST API at https://api.onboardconnectapp.com/api/tenant/. All requests must include an API key in the Authorization header.

Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

23.1 Common endpoints

Full API reference documentation is available at docs.onboardconnectapp.com/api.

24. FAQ

What happens if the Agent goes offline?

Provisioning jobs queue up in the cloud. When the Agent comes back online, it processes all queued jobs in order. No jobs are lost. You will receive an email alert if the Agent is offline for more than 15 minutes. Any workflow action triggered while the agent is offline will return a clear error: "Agent is offline" — no silent failures.

What does the "paused" state mean?

An administrator can pause the Agent from the Agent Management UI (http://localhost:7432) without stopping the service. While paused, the agent stays connected to the cloud but holds all incoming commands in a queue without executing them. Any workflow that tries to send a command while the agent is paused receives an error message explaining that the agent is paused and how to resume it. The portal displays a yellow "Connected — paused" indicator in the agent status check.

Does OnboardConnect store student passwords?

No. Passwords are generated momentarily during the provisioning job and set directly in AD via the Agent. OnboardConnect never persists password values.

Can I use OnboardConnect with Azure AD only (no on-prem AD)?

Yes. Azure AD provisioning uses the Microsoft Graph API directly from the OnboardConnect cloud — no Agent installation required. Select "Azure AD" as the connection type in Connections.

How do I test a workflow without affecting real accounts?

Use the Test button on any workflow to simulate evaluation against a sample student record. No actual provisioning jobs are created during a test.

What does "Founder" mean on my account?

Founder status is granted to early institutional partners who signed with Zentrosoft during the product's launch phase. Founders receive a negotiated discount on their annual contract price. Founder status has no effect on features or limits.

25. Support

OnboardConnect includes a built-in support ticket system so your IT team can request help, report issues, and track progress — all without leaving the portal.

25.1 Opening a support ticket

1. In the portal sidebar, click Support.
2. Click + New Ticket in the top-right corner.
3. Enter a concise Subject describing the issue.
4. Select a Priority:

   • Low — non-urgent question or enhancement request
   • Normal — general issue, no immediate impact on provisioning
   • High — provisioning is degraded or partially broken
   • Urgent — provisioning is completely stopped; production outage
5. Write your message in the Message field. Include relevant details: affected students, error messages, job IDs from the Audit Log, and steps to reproduce.
6. Click Submit Ticket. The Zentrosoft support team is notified immediately by email.

25.2 Tracking your tickets

The Support page lists all tickets your institution has submitted, sorted by most recent first. Each ticket shows:

25.3 Ticket statuses

25.4 Replying to a ticket

Click any ticket row to open the conversation thread. You can read all previous messages and post a reply in the text field at the bottom. Click Send Reply to submit. The support team is notified by email of your reply.

Replies are disabled once a ticket is Closed. To report the same issue again, open a new ticket.

25.5 Notifications

Email notifications are sent automatically:

• When you submit a ticket, the Zentrosoft support team receives an email notification.
• When the support team replies, you receive an email at the address associated with your portal account.
• When the ticket status changes (e.g., marked Resolved), you receive an email notification.

25.6 Direct email support

You can also reach the Zentrosoft solutions team directly at solutions@zentrosoft.com. For production-impacting incidents, mark your subject line with [URGENT]. Using the in-portal ticket system is preferred as it keeps all communication and context in one place.

26. Self-Service Password Reset

Self-Service Password Reset lets students reset their own institutional password from a branded public portal at accounts.onboardconnect.app/<your-slug>. Identity is verified through a one-time code delivered to the recovery email or phone already recorded on the directory user, and the reset itself is dispatched through the same provisioner pipeline used by every other OnboardConnect action.

26.1 Overview

The feature is designed for institutions whose helpdesk is overrun by password reset tickets — particularly at term-start surges. It is intended for end-user student accounts only; privileged accounts (Domain Admins, IT Staff, and any other groups you designate) are excluded from the self-service flow.

In v1, Self-Service Password Reset is scoped to password resets only. It is not an MFA management portal and does not yet offer username recovery.

26.2 Prerequisites

Before enabling the feature, confirm the following are in place:

• At least one Azure AD or On-Prem Agent connection with the Password Reset action enabled in Search Settings → Active Connections.
• At least one outbound messaging connection for delivering verification codes:
  • A Twilio connection for SMS codes, and/or
  • An SMTP-over-HTTP connection (Mailgun, SendGrid, or Resend) for email codes.
• Each directory user has a recovery email address and/or recovery phone number recorded on a known AD attribute (e.g., otherMail, mobile).
• One or more security groups identified for exclusion (Domain Admins, IT Staff, helpdesk groups, etc.).

26.3 Step-by-step setup

26.3.1 Enable the master toggle

1. Go to Settings → Self-Service Portal.
2. Toggle Enable Self-Service Password Reset to On.
3. Confirm the institution slug shown at the top of the page (this becomes the path segment in your public URL).

26.3.2 Pick the connection(s) that execute resets

In the Reset Routing section, choose which Active Connection(s) the portal should send password reset commands to, and set the priority order. If the first connection is unavailable, OnboardConnect tries the next one in the list.

• Only connections with the Password Reset action enabled appear in this list.
• Drag and drop to reorder priority. Higher in the list is tried first.

26.3.3 Map recovery email and recovery phone attributes

For each routed connection, map the directory attribute that holds the student's recovery email and the attribute that holds the recovery phone number. Common choices:

If a student has both a recovery email and a recovery phone on file, the public portal lets them choose which channel to use.

26.3.4 Exclude privileged groups

In the Excluded Groups section, add the group Distinguished Names (or Object IDs for Azure AD) of any groups that must not be eligible for self-service reset. Typical exclusions:

• Domain Admins
• Enterprise Admins
• IT Staff / Helpdesk groups
• Service account groups

If a student is a member of any excluded group, the public portal returns a neutral "self-service is not available for this account" message without revealing the exclusion reason.

26.3.5 Optional branding

Customize the public portal so end users see your institution, not OnboardConnect:

• Logo — upload a PNG or SVG (recommended 240×60px).
• Primary color — used for buttons and accents (hex value).
• Support contact text — a free-text string displayed at the bottom of every step (e.g., "Need help? Email helpdesk@university.edu or call (555) 123-4567").

26.3.6 Save and verify the public URL

1. Click Save Settings.
2. Copy the Public Portal URL displayed at the top of the page (e.g., https://accounts.onboardconnect.app/university-edu).
3. Open the URL in a private browser window and confirm the branded landing page loads.
4. Run a test with a non-privileged test account that has a known recovery email or phone on file.

26.4 End-user experience

From the student's perspective, the flow is five steps:

1. The student visits accounts.onboardconnect.app/<your-slug>.
2. They enter an identifier — institutional email address or student ID.
3. OnboardConnect resolves the user against the configured connection(s) and sends a one-time code to the recovery email or SMS on file. If both are available, the student picks the channel.
4. The student enters the code to verify identity.
5. The student picks a new password that meets the tenant's password policy. OnboardConnect dispatches the reset through the routed connection and shows a confirmation screen.

26.5 The Reset Log

Every self-service attempt — successful or not — is recorded in Reports → Reset Log. Each row shows:

Pattern alert banners

Three pattern detectors run continuously against the Reset Log and surface a banner at the top of the page when triggered:

• Repeat resets — the same account has reset more than three times in the last 30 days.
• Failed-verify spikes — a surge of failed code verifications from a single IP or against a single account, suggesting a brute-force attempt.
• Reset → privilege change — an account that completed a reset was then added to a sensitive group within 24 hours, suggesting a possible takeover.

Each banner links to the filtered Reset Log view and includes a one-click action to disable the affected account.

CSV export

Click Export CSV at the top of the Reset Log to download the currently filtered view. The export honors all active filters (date range, outcome, country, etc.) and is suitable for compliance review or audit response.

26.6 Security notes

• Cloudflare Turnstile is enforced on the identifier and code-entry steps. No user-visible CAPTCHA is shown unless Turnstile flags the visitor as suspicious.
• Rate limits apply per IP and per resolved account: a maximum of 5 code requests per account per hour, and 20 code requests per IP per hour.
• PII masking — recovery channels are masked in the public portal and in the Reset Log. The full value is never exposed to end users or to the export.
• FERPA retention — Reset Log entries default to a 1-year retention. Tenant administrators can extend retention up to 7 years from Settings → Self-Service Portal → Retention.
• OnboardConnect never persists the new password. It is set directly in AD via the routed connection and discarded from memory immediately after.

26.7 Troubleshooting

"Setup will not enable"

The master toggle is blocked until at least one Active Connection has the Password Reset action enabled. Go to Search Settings → Active Connections, pick a connection, and check the Password Reset box.

"Self-service is not available for this institution"

This message appears on the public portal when the master toggle is off, when the slug in the URL doesn't match a tenant, or when the tenant has been suspended. Confirm the URL spelling and that Self-Service Password Reset is enabled in Settings → Self-Service Portal.

"Code never arrives"

1. Confirm the recovery email or phone is actually present on the student's directory record using Students → Search.
2. Go to Connections and verify the messaging connection (Twilio for SMS, Mailgun / SendGrid / Resend for email) is Connected. Click Test Connection.
3. Check the Reset Log entry for the attempt — the Outcome column will show Code Sent if dispatch succeeded, or an error reason if it did not.
4. For email codes, confirm your SPF/DKIM records authorize the sending domain. Codes flagged as spam will not arrive.

"Hybrid AD: reset succeeded but password reverts"

If you run Azure AD Connect with on-prem authoritative and route Password Reset to Azure AD without password writeback enabled, the next directory sync will overwrite the new password with the old on-prem hash. Either enable password writeback in Azure AD Connect, or change Settings → Self-Service Portal → Reset Routing so the on-prem agent connection is the first priority.

"Privileged user can still reach the public portal"

The portal accepts an identifier from anyone — exclusion is enforced after the lookup, before any code is sent. Confirm the privileged user's group memberships actually include one of the DNs / Object IDs listed in Excluded Groups. The Reset Log will show outcome Excluded when the gate correctly blocks the attempt.