Automate student accounts, end to end

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 — 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).
4. Enter the 6-digit sign-in code we email you. The code expires in 10 minutes and works once; use Resend code if it doesn't arrive.

3.2 Configure your AD connection

Go to Connections and add your Active Directory or Microsoft Entra ID connection. For on-premise AD, install the OnboardConnect Agent on a server inside your network first — see On-Premise Agents. For Microsoft 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 build a workflow: a source step that reads your records (for example Slate Query Service Read), the action steps that create or update accounts, and how it is started — manually, on a schedule, or when a form is submitted. See Workflows for details.

3.5 Configure Provision Rules

Go to Provision Rules and configure how accounts are built: set your username format, password policy, and group membership rules. Every tenant starts with one rule set, Students; add more (for example Staff) when other kinds of accounts need different rules. See Provision Rules 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 Microsoft Entra ID 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

Run the workflow manually against a test record and check its run history before turning on its schedule or form trigger. 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. A workflow is a named, ordered list of steps: it reads records from a source, shapes them, acts on them (create, update, disable, write back…), and notifies people about the outcome. You build it visually in the workflow editor by adding steps from the step palette.

7.1 How workflows work

The editor canvas has three lanes:

Records flow through the Pipeline as rows. A source step produces the rows; each later step works on the rows handed to it and passes them on, and the fields a step adds (for example a generated username or password) are available to every step after it. Action steps such as On-Prem Create need a read step earlier in the Pipeline to give them rows.

Each workflow runs on its own — there is no "first matching workflow" order between workflows. To treat different kinds of records differently, use a Filter Rows step inside one workflow, or build separate workflows.

When a step fails

• If a step fails for some records, those records are set aside (they stop at that step) and the rest carry on through the Pipeline. The run finishes as Partial and the On Failure lane runs.
• If a step fails as a whole (for example its connection can't be reached), the run stops at that step and finishes as Failed; the remaining Pipeline steps don't run, and the On Failure lane runs. Turn on Continue on error on a step to have its failure recorded and the run carry on instead.
• A cancelled run runs neither On Success nor On Failure.

7.2 Creating a workflow

1. Go to Workflows and click New Workflow. Give it a descriptive name (e.g., "New undergrads — create AD account") and, optionally, a description and a color group.
2. Add a source step to the Pipeline — for example Query Service Read on your Slate connection (see 7.4).
3. Optionally add Filter Rows to keep only the records this workflow should handle, and Transform Fields to build the values you need.
4. Add the action steps — create, update, activate, set password, groups, write back to Slate or the SIS. Steps that generate usernames, passwords or group memberships use a Provision Rules rule set, chosen on the step (see 10.6).
5. Optionally drag notification steps into the On Success and On Failure lanes.
6. Open each step and complete its configuration. Under Settings in the editor sidebar, choose how the workflow is started (7.3).
7. Save. A new workflow is saved with Save Workflow; after that the editor saves each change automatically. Turn on Active once every active step is fully configured — a workflow with an incomplete step is saved as inactive.

Each step card has its own on/off switch: a step that is switched off is skipped on runs but keeps its configuration. Drag a step's card to reorder it within its lane.

7.2a The action editor

Opening a step shows its settings as numbered sections, top to bottom in the order you fill them in. Where an action has them, sections come in this order: Connection → Target (OU, table, form, file or endpoint) → Provision Rule Set → Identity / Username → values (field mapping, password, groups / lists) → Options → Password Recovery → Output Fields. Numbers update when a section appears or disappears because of a choice you make.

Each section has an icon and a colour that means the same thing on every action:

• Required / Optional tags. Each field label carries a Required or Optional tag. A choice that always holds a value (for example a Source dropdown) has no tag. An amber tag such as One required means one of two fields must be filled in.
• Amber border. A required field that is still empty has an amber border, so you can see what is left to fill in.
• Field pickers. Pickers that choose a field from an earlier step show a form field by its name with its id in parentheses, e.g. First Name (first_name); the id is what is saved. A form dropdown whose options have labels appears twice: Role (value) (role) — the stored value — and Role (label) (role_label) — the label of the chosen option (see 26.4). Fields from other sources (Slate, SIS, SQL) show their column name.

Default sources on new actions

When you add a provisioning action, its username, password, security-group and distribution-list sources start on From provision rule (recommended), so the step follows the rule set chosen in its Provision Rule Set section. You can change any of them: a password or a membership list can instead be Static (the same for every record) or From a field (per record); a username can come From a field; On-Prem Create's Initial Password can also be None. Steps saved before this default keep the sources they were saved with.

7.3 Triggers — when a workflow runs

Active Date Range (optional From / To dates in the sidebar) limits the days on which the schedule runs the workflow; leave both blank for no restriction. Turning Active off pauses the workflow — manual, scheduled and form-started runs are all blocked.

7.4 Step types

The step palette groups steps by what they connect to. By what they do in a workflow:

Every step is described in the Workflow Action Catalog (7.4a). The details below apply to the On-Prem Create and Update steps.

On-Prem Create — sections

The On-Prem Create step's sections, in order:

On-Prem Create — Target OU

Where new accounts are created is set on the step itself. The OU Source chooses how:

• Static OU (same for every record) — enter the OU distinguished name in OU Path (required), e.g. OU=Students,DC=company,DC=edu.
• From a field (per record) — pick the OU Field (required) whose value is the OU distinguished name, for example a form dropdown whose options are Staff | OU=Staff,OU=People,DC=company,DC=edu. The optional Fallback OU is used when a record's field is empty.

Each create step has its own OU, so a Students workflow and a Staff workflow on the same connection can create accounts in different places. The OUs listed on the connection in Record Management → Active Connections (also used by Self-Service) are only where directory reads search — they are never used to create accounts. A record with no OU (an empty OU field and no Fallback OU) fails rather than landing in the default Users container.

On-Prem Create — Initial Password

The Password Source sets whether the account gets a password in the same operation that creates it:

With a password, the account is created enabled. Force password change on next sign-in is on by default (with the directory's password policy it is always forced). Tick Generated Password under Output Fields to pass the password to a welcome email or writeback.

On-Prem Create — userPrincipalName

The userPrincipalName is generated as sAMAccountName@<domain>, where the domain is the UPN Domain on Provision Rules → Username Format (of the step's rule set). 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).

Endpoint URL (Ellucian Ethos). Each Ethos action carries its own Endpoint URL — the full request the agent makes. Its last path segment is the resource, and for SIS Read its query is the filter:

• personFilter={"<guid>"} is shorthand for the standard personFilter={"personFilter":{"id":"<guid>"}}; both work.
• A read's query can use a previous step's field as a variable: @Field (or {{Field}}), e.g. criteria={"credentials":[{"type":"colleaguePersonId","value":"@id"}]}. It is filled from each incoming row — one read per distinct URL; rows without a value are skipped. @name counts only when a previous step has that field, so a literal Banner ID like @00012345 is sent as written. Variables are allowed only after the ?.
• Ethos takes one filter per request: a personFilter and criteria can't be combined. To read one person by Banner or Colleague ID, use criteria with a variable, as above.
• The agent reads every page (Ethos reports the total in the x-total-count header), up to 50,000 records, paged 1,000 at a time. Past the limit the action fails rather than returning a partial list, so narrow the filter. Leave offset and limit out — paging is the agent's.
• Only the listed person columns leave campus; SSN / tax IDs, birth date, gender and ethnicity are never sent.
• For security the agent sends its Ethos token only to https URLs on the same host as the profile's Auth URL; any other host is refused.
• A write's Endpoint URL names the resource only (no ?query). On the network-username write it is optional — leave it blank to use the profile's default.
• Actions saved before the Endpoint URL field existed keep working unchanged.

Writing to Ethos (SIS Upsert → Custom fields). Enter the write's Endpoint URL (e.g. https://integrate.elluciancloud.com/api/persons) and click Fetch Fields: the agent reads one record there and lists the parameters the resource accepts as paths into the record — only their names, never the values. Then, for each parameter you want to send, choose where its value comes from:

• Match Key uses the same parameters to find the existing record — e.g. credentials[0].type = fixed bannerId and credentials[0].value ← the Banner ID field, which the agent sends as the criteria {"credentials":[{"type":"bannerId","value":"…"}]}.
• One match → update. The lookup (e.g. GET /api/persons?criteria={"credentials":[{"type":"colleaguePersonId","value":"0228290"}]}) returns the person with their GUID in id. The agent changes only the mapped parameters on that record and saves it with PUT /api/persons/{guid}, so the person's other names, emails and credentials are kept (an Ethos update otherwise replaces whole arrays). If the person already has those values, nothing is written and the run reports them as up to date.
• No match → insert. The new record is sent with POST /api/persons and id 00000000-0000-0000-0000-000000000000; Ethos assigns the real GUID. A new person needs a name with names[0].type.category (legal, personal, birth or favored) and names[0].lastName; the full name is built from the name's parts when it isn't mapped. Each email, phone and address needs its type (e.g. emails[0].type.emailType = school). A record that misses a rule is reported on its row and not sent.
• More than one match is refused rather than guessing which to update.
• Match by is for updates — it's optional. A row with no match value (e.g. a new applicant with no Colleague ID yet), or a step with no Match by at all, is a new person and is created without a lookup. Such a row is created again if it runs again without a match value, so send the new Colleague Person ID back (Output Fields → e.g. a Slate write) to have the next run update instead.
• Picking parameters. For …/persons, — add a SIS field — lists every parameter by name, grouped (Name, Email, Phone, Address, IDs, Role, Other). Adding an email, phone, address or ID also adds its type (e.g. Email type = school), and fields with a fixed set of values (email type, name type, gender …) offer Ethos's values to choose from.
• Map each list item with its type. A person's emails, phones, addresses and IDs are kept in no fixed order, so on an update the agent changes the item of the mapped type — e.g. emails[0].type.emailType = fixed school with emails[0].address changes the school email and leaves the personal one alone (and adds a school email if there is none). An email, phone, address or credential mapped without its type is refused on the row. A name mapped without type.category changes the legal name.
• The person's IDs go to the next action. After a create or update, the person's Colleague Person ID (colleaguePersonId) — on a create, the one Colleague just assigned — and Banner ID come back with the person's GUID. Map them under Output Fields (e.g. Colleague Person ID → ColleagueId) to use them in a later action, such as a write back to Slate. SSN and tax IDs never come back.
• For …/persons, every parameter the persons record accepts is listed without fetching; Fetch Fields adds any extra field your records carry.
• A parameter missing from the fetched list can be added by path, e.g. emails[1].address. Only mapped parameters are sent.

SQL Server

Executed by the on-prem Agent against the SQL profile referenced by a "SQL Server" connection (8.9). Pick the table on the action; its columns load from the database.

SQL Create, Update and Delete hand their incoming fields on to the next step when they have no output mapping, and SQL Create's Pass-through section (shown even before a table is chosen) can also offer the values it wrote.

Forms

Read and update submissions of your Internal Forms through an Internal Form connection (8.10).

Provision Rule Set (on provisioning steps)

Steps that generate a username, a password, or group / list memberships from Provision Rules show a Provision Rule Set section with a Rule set choice: Default (Students), A specific rule set, or Chosen by a field. On-Prem Create, Entra Create and Google Create always show it; other steps show it while one of their sources is From provision rule. See 10.6.

Flow & Logic

Transform Fields

Each field assignment has a Target field (the column to set — a new one, or an existing one to overwrite), a Template, and a text option. In the template, {field} is replaced with the record's value of that field (field names are matched regardless of case; a missing or empty field becomes empty text). A template with no tokens sets the same value on every record. Example: Target displayName, Template {first_name} {middle_name} {last_name}.

Assignments run in order, so a later assignment can use a field set by an earlier one.

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 configured in Provision Rules → Username Format, per rule set. A Create step uses it when its Username Source is From provision rule (recommended) — the default for new steps. The rule set's If username already exists… choice applies to On-Prem Create whichever username source is used. See Provision Rules → Username Format.

7.6 Reordering steps

Drag a step's card up or down to change its position within its lane (Pipeline, On Success or On Failure); a step can't be dragged into another lane. Steps added from the palette go to the Pipeline — drag a step from the palette into the On Success or On Failure lane to add it there. The workflows themselves have no run order: each one runs on its own trigger, and the list can be sorted by any column.

7.7 Run history & per-record results

Click the clock icon on a workflow's row (or View Run History in the editor sidebar) to open its run history. Each run shows how it was started (manual, schedule, form, API), its status — Running, Completed, Partial, Failed or Cancelled — and its duration. Expand a run to see:

• The step timeline — each step's status (completed, failed, skipped…), timing and result detail, including the On Success / On Failure step that ran.
• Students — one line per record: who it was, its username, and what happened to the account (created, updated, activated, disabled, password reset, moved, skipped or Error). For an error it shows which step failed and why, and what was already done before the error. Errors are listed first; Errors only narrows the list.

A running run can be cancelled from the history panel or the editor. Clear run history deletes the workflow's past runs.

7.8 Testing a workflow

There is no simulation mode — a run performs its steps for real. To try a workflow safely:

• Point its source at a test record — for example a Slate query or a Filter Rows condition that matches only a test applicant, or a test Internal Form with one entry.
• Switch off the steps you don't want yet (each step card's on/off switch), run, and check the run history before switching them back on.
• Use a test OU (see the step's Target OU) and a test account before pointing the workflow at real students.

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. It stays disabled until every active step is fully configured (hover for the reason). 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 flow into the workflows that read them (Query Service Read).
• 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 Microsoft Entra ID connection

Connect to Microsoft Entra ID via the Microsoft Graph API. Required fields: Tenant ID, Client ID, Client Secret (from a Microsoft Entra 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

An On-Prem Agent connection points at an installed Agent; the LDAP server, bind account and base DN are configured on the Agent itself (see Active Directory / LDAP). The Agent must be installed first — see On-Premise Agents.

Like Microsoft Entra ID, 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 Microsoft Entra ID 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, Microsoft Entra ID, 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 Microsoft Entra ID 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, add a SIS profile (Agent Setup → SIS Profiles, see 18.6). For Ellucian Ethos (Banner / Colleague) the profile holds only the Auth URL and the API Key; for PeopleSoft and Workday it holds the base URL and that system's 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 signs in to the SIS with its 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).

8.9 SQL Server connection

A SQL Server connection lets workflows create, read, update and delete rows in a Microsoft SQL Server database on campus — for example, to write each new student into a local reporting table. Like SIS, the connection holds no credentials: it points at an on-prem Agent and a SQL profile defined on that agent.

1. On the on-prem Agent, add a SQL profile (Agent Setup → SQL Profiles, see 18.7) with the server, database and sign-in.
2. In OnboardConnect, go to Connections → Add Connection → SQL Server.
3. Select the Agent and the database (the agent's SQL profile).
4. Click Test — the agent signs in to SQL Server with that profile — then save.

The table and columns are chosen on each workflow action, not on the connection, so one connection serves every table the profile may reach.

8.10 Internal Form connection

Add Connections → Add Connection → Internal Form once. It needs no credentials: workflows use it to read submissions of your Internal Forms (Form Read) and write values back to them (Form Update). The form itself is picked on each workflow step, so one connection serves every form.

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 Microsoft Entra ID 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.

For an On-Prem Agent connection, two OU boxes appear: OU (Organizational Unit) — one OU per line; directory reads search every listed OU (where new accounts are created is set on each workflow's On-Prem Create step) — and the Disable OU, where deactivated accounts are moved (required when the connection performs Activate / Deactivate).

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 Microsoft Entra ID 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").

Microsoft Entra ID 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. Provision Rules

Provision Rules (sidebar, Provisioning group) defines how accounts are built — username format, password policy, and security-group and distribution-list membership. Rules are kept in named rule sets, so students, staff and faculty can each get their own. Workflow steps whose username, password, groups or lists come From provision rule — the default on new steps — use them.

10.1 Rule sets

The bar at the top of the page lists your rule sets as chips — Students (default) plus any you add — and shows Editing: <set> for the selected one. Everything on the tabs below belongs to the selected set.

• Default set. Every tenant has one default rule set, named Students. Workflows use the default rule set unless a step picks another.
• Add rule set — give it a name (up to 60 characters, unique) and choose Start from: Blank (standard defaults) or Copy of <set>. A copy starts with the same username format, password policy and group rules — change what differs.
• Rename — any set, including the default.
• Delete — removes the set's username format, password policy and group rules; it can't be undone. The default set can't be deleted, and a set that workflow steps use can't be deleted until those steps point at another rule set (the message lists the workflows).

Changes save automatically (the status next to Save shows when); Save saves immediately.

10.2 Username Format tab

Define the template used to generate usernames for new accounts. Use {field_name} tokens; the workflow step maps which of its fields fill {first_name}, {last_name}, {middle_name} and {student_id}:

{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 ([-N] takes the last N characters). A live preview shows how the template renders using sample data.

Additional options:

• Shorten long names to fit — Active Directory usernames are limited to 20 characters. When on, the rest of the format (such as ID digits) is kept and the first and last names are shortened instead — the longer name gives up letters first — rather than cutting off the end. When the format can produce a username over 20 characters, the page shows an example for Christopher Worthington-Blackwood, ID 1238535; with {first_name[0]}{last_name}{student_id[-4]} it is cworthingtonblackwoo (ID cut off) when off, and cworthingtonblac8535 when on.
• Case Transform — Lowercase, Uppercase, or None.
• UPN Domain — appended to the username to form the userPrincipalName (e.g. jsmith@company.edu). Leave blank to take the domain from the record's email field. Entra Create steps that use this rule need either this value or a per-row email with an @; otherwise the record is skipped with Missing userPrincipalName.
• If username already exists… — Grow first-name prefix (recommended), Append number, Append name initials, Insert middle name, or Append middle initial. The examples change only the username — the part before @; the UPN domain stays the same (e.g. jsmith@company.edu → jsmith2@company.edu). The middle-name options need a middle name on the record and fall back to a number when it is missing.

How collisions are numbered. Each retry starts again from the original username, so numbers count up rather than pile up: john.smith → john.smith2 → john.smith3 (not john.smith23). Grow first-name prefix adds first-name letters until the whole first name is used, then continues with 2, 3, 4…. On-Prem Create tries up to 12 alternatives before the record fails.

10.3 Password Policy tab

The first choice on the tab is whose rules apply:

• OnboardConnect password rules — set Length (8–128), Min Uppercase, Min Lowercase, Min Digits, Min Symbols, Allowed Symbols, and Require password change on first logon. OnboardConnect generates passwords and checks self-service resets against these rules. A 4-segment strength indicator reflects the policy's overall strength.
• Use the directory's password policy (Recommended if your institution already has a password policy) — the length and character settings are hidden. New accounts and staff-initiated resets get a strong 16-character one-time password, and the user must choose their own password at next sign-in (Must change at next sign-in is always on). Self-service resets are checked by the directory itself, so the reset page shows "Your password must meet your institution's password requirements."

With the directory's policy: Active Directory applies your domain password policy (length, complexity and history). Microsoft Entra ID applies Microsoft's policy: 8 or more characters, 3 of 4 character types, and no banned passwords. If your domain requires more than 16 characters, new-account rows fail with a message saying the password didn't meet the domain's policy; in that case use OnboardConnect password rules with a longer length instead.

10.4 Security Group tab

Define which security groups an account is added to. Rules are additive — every matching rule is applied, so an account can land in several groups. Each rule has a label, an Active switch, an optional condition, and one or more group names (on-prem: Distinguished Names; Entra: group names; Google: group emails). Reorder rules with the arrows.

• Fields from — pick an Internal Form to have the editor offer that form's fields and, for dropdown and checkbox fields, their values (labels shown, values stored). Leave it on Type field names to type any field name. The setting belongs to the rule set and is shared by the Security Group and Distribution List tabs.
• Condition on any field — tick Apply condition, choose any field the workflow record carries (from Slate, a form, the SIS, SQL…), an operator (is, is not, contains, starts with, ends with, is one of, is not one of, is empty, is not empty) and a value. A rule with no condition applies to every account.
• {field} in group names — a group name can contain {field} tokens filled from each record, e.g. CN=Staff-{department},OU=Groups,DC=company,DC=edu. Use + field to insert one of the form's fields. Values inserted into a DN are escaped. A record whose field is empty skips that group, and the run result says why.

10.5 Distribution List tab

Same structure as Security Group, but for mail-enabled distribution lists. Rules are additive and evaluated independently from security group rules. Distribution lists apply only to On-Prem Agent (on-prem Active Directory) connections; Microsoft Entra ID ignores these rules.

10.6 Rule sets in workflow steps

Every Create step, and any Set Password, Security Groups or Distribution Lists step whose source is From provision rule (recommended) — the default for new steps — shows a Provision Rule Set section. Its Rule set choice:

How a field value is matched. The record's stored value is compared with the mapped values exactly first, then with spaces trimmed from both ends, then ignoring upper / lower case — so staff and STAFF both match a mapping for Staff. A form dropdown sends its value, not its label: for an option Staff | OU=Staff,OU=People,DC=company,DC=edu the value matched is the OU path, which the picker handles for you when it lists the options.

10.7 Account placement (OU)

Provision Rules doesn't hold OU placement rules. Where an on-prem account is created or moved is set on the workflow step: On-Prem Create → Target OU (a static OU, or a per-record OU from a field with an optional Fallback OU — see On-Prem Create) and On-Prem Move OU → Destination OU (a static OU, or a per-record OU from a field with an optional fallback). See the Action Catalog and Staff & faculty accounts.

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 Plan & Usage page shows your plan, the enrollment band it covers, and your provisioning activity. There is no provisioning limit — your plan is based on student enrollment, not on how many accounts you create.

Reading the Plan & Usage page

If your enrollment grows more than 5% past the top of your plan's band, your plan moves to the next tier at renewal. To update the enrollment on file or ask about your plan, contact solutions@zentrosoft.com.

15. Settings — Users & Roles

15.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.

15.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

15.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.

16. 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, Microsoft Entra ID, Auth0, Keycloak, or any other OIDC-compliant IdP).

16.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://login.company.edu/.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.

16.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.

17. Settings — Developer

17.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.

17.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.

17.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();

18. 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.

18.1 Install the Agent

1. On the target Windows Server machine, open PowerShell as Administrator and run npm.cmd install -g onboardconnect-agent --loglevel=error.
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). Use port 636 (LDAPS) where you can — see 18.5.
6. Return to the portal under Connections and confirm the agent connection card shows Connected.

18.2 Agent requirements

The Agent is a Node.js application published on npm as onboardconnect-agent. There is no .NET or other runtime to install.

18.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.

18.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.

18.5 LDAP authentication modes

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

Choosing the LDAP port

The Port field's hint reads 636 = LDAPS (recommended) · 389 = LDAP with StartTLS; the ? next to it explains:

The domain controller's firewall must allow the agent's server on the port you choose.

18.6 SIS profiles (on the Agent)

Setup tab → SIS Profiles. A SIS profile holds the credentials for one Student Information System; the portal's SIS connection (8.7) references it by Profile Id. Credentials are stored encrypted on the agent server and never leave campus.

Test Connection signs in with the form's values — for Ethos, it gets a token from the Auth URL with the API key.

18.7 SQL profiles (on the Agent)

Setup tab → SQL Profiles. A SQL profile is one database the agent may read and write; the portal's SQL Server connection (8.9) references it. Fields: Profile Id, Server (host name, or host\instance for a named instance), optional Port (blank for 1433 or a named instance), Database, Sign-in, Encrypt the connection (on by default), Trust the server's certificate (only for a self-signed certificate) and optional Allowed tables (one schema.table per line; blank allows every table the login can see).

Test Connection signs in and reports the database and the account SQL Server saw — useful to confirm which Windows account a Domain service account profile uses.

19. Integration — Slate CRM

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

19.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.company.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.

19.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.

19.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 Provision Rules group conditions.

20. On-Premise Agents

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

20.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.

20.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.

20.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.

20.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.

The portal shows Update available next to an on-prem connection whose agent is behind. To update the agent to the latest version, open PowerShell as Administrator on the agent host and run:

1. Stop the service: Stop-Service -DisplayName "OnboardConnect Agent"
2. Install the latest version: npm.cmd install -g onboardconnect-agent@latest --loglevel=error
3. Set the service up again and start it: onboardconnect-agent service

Settings, credentials and SIS / SQL Server profiles are kept — they live in C:\ProgramData\OnboardConnect\, which the upgrade never touches. Do not run setup again: setup re-registers the agent and replaces its credentials. The portal shows the new version within a minute. The same three commands are under Connections → your on-prem connection → Upgrade Agent.

Why the third step: the upgrade replaces the agent's program folder, and on older installs that folder also held the Windows service's own files, so the service can't start again on its own. onboardconnect-agent service re-creates it under C:\ProgramData\OnboardConnect\service\, where later upgrades leave it alone. It is safe to run any time.

Use the display name as shown. The service is registered internally as onboardconnectagent.exe, and in PowerShell sc is an alias for Set-Content — use sc.exe if you prefer the service controller.

20.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 20.6).

20.6 Uninstalling the agent

To cleanly remove the agent from a server:

1. Open PowerShell as Administrator on the agent host machine.
2. Run onboardconnect-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.

20.7 Allowed Command Types

The Settings tab at http://localhost:7432 lets administrators control exactly which operations this agent instance can execute. Changes take effect on the next command — no restart needed.

Every action the agent can run is listed, in eight 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. With no list saved, every command is enabled.

After adjusting the allowlist, click Save Command Filter. The agent reads the list on every command, so the change applies to the next one without restarting the service.

20.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.

20.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:

With no SIS or SQL profiles saved, those rows read Not configured and do not count as a failure.

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.

20.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 20.1.

21. Plans

Plans are based on your institution's total student enrollment headcount, as reported in the latest IPEDS fall enrollment.

There is no provisioning cap and no overage: account creations, updates, disables, re-enables, and password resets are always unlimited.

For questions about your plan, contact solutions@zentrosoft.com.

22. 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

22.1 Common endpoints

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

23. 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 Microsoft Entra ID only (no on-prem AD)?

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

Agent commands fail with "rejected the request as expired … clock is ahead"

Every command sent to the Agent carries an expiry time, and the Agent checks it against its own server clock. If that server's clock runs ahead, the Agent treats every command as already expired and rejects it on arrival — so actions fail immediately even though the Agent is online. OnboardConnect measures the offset and reports it, for example: "The OnboardConnect Agent rejected the request as expired because its server's clock is about 95 seconds ahead. Sync the time on the agent's server…"

Fix: sync the time on the Agent's server — run w32tm /resync in an administrator prompt, or point the server at your domain's time source — then try again. A domain-joined server normally keeps time from its domain controller.

The Agent's LDAP test fails with error 52e

Error 52e is Active Directory's "invalid credentials". Besides a wrong password, the most common cause is an LDAP Username without the domain. Enter it as svc_onboard@company.edu or COMPANY\svc_onboard (or the account's full DN), not just svc_onboard. See 18.5.

How do I test a workflow without affecting real accounts?

There is no simulation mode — a run performs its steps for real. Limit the source to a test record (a Slate query or Filter Rows condition that matches only a test applicant, or a test form entry), switch off the steps you are not ready to run, and use a test OU. See Testing a workflow.

24. 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.

24.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.

24.2 Tracking your tickets

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

24.3 Ticket statuses

24.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.

24.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.

24.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.

25. Self-Service Password Reset

Self-Service Password Reset lets students reset their own institutional password from a branded public portal whose address ends in /<your-slug> — the exact Public Portal URL is shown on the Self-Service page. Identity is verified through a one-time code delivered to the recovery email or phone already recorded on the directory user. The new password is then set directly on the reset connection: through Microsoft Graph for Microsoft Entra ID, or as an encrypted command to the On-Prem Agent.

25.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. Which accounts can use it is controlled by the reset connection's OU scope (25.3.4): on-prem lookups search only the OUs you list there, so staff and administrator accounts kept outside those OUs are never found.

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.

25.2 Prerequisites

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

• An enabled Microsoft Entra ID or On-Prem Agent connection to use as the Reset connection (chosen on the Self-Service page, 25.3.2).
• 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).
• For an On-Prem Agent connection, the OU(s) that hold student accounts — and privileged accounts kept outside them.

25.3 Step-by-step setup

25.3.1 Enable the master toggle

1. Go to Self-Service (sidebar) — the Self-Service Portal page.
2. In the Portal status card, turn on the master switch and confirm. (It can't be turned on until the settings below are complete — see 25.7.)
3. Confirm the institution slug shown at the top of the page (this becomes the path segment in your public URL).

25.3.2 Pick the reset connection

In the Reset connection card, choose the Microsoft Entra ID or On-Prem Agent connection that answers self-service password resets. Only one connection drives self-service at a time; picking a different one replaces the previous selection.

25.3.3 Map recovery email and recovery phone attributes

For the reset 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.

25.3.4 Limit which accounts are eligible (OU scope)

For an On-Prem Agent reset connection, enter the student OU(s) in the connection's OU box, one per line (e.g. OU=Students,DC=company,DC=edu). The portal looks the user up only in those OUs, so accounts outside them — administrators, IT staff, service accounts — can't be found or reset. Keep privileged accounts out of the listed OUs.

25.3.5 Optional branding

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

• Logo URL — the https address of your logo image (e.g., https://www.company.edu/logo.svg).
• Primary color — used for buttons and accents (hex value).
• Support contact text — short formatted text (bold, italic, links) shown to students on the portal (e.g., "Need help? Email helpdesk@company.edu or call (555) 123-4567").

25.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 (it ends in your institution's slug, e.g. …/company).
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.

25.4 End-user experience

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

1. The student opens your Public Portal URL.
2. They enter their school email address or phone number and complete the Cloudflare Turnstile check.
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.

25.5 The Reset Log

Every self-service attempt — successful or not — is recorded in the Password Reset Log (sidebar, Reporting group). Filter it by date range (From / To), Status, and a search box for the identifier or user. The table shows:

Expand a row for its details — country, user agent, failure reason and, for an on-prem reset, the agent Command ID.

Pattern alert banners

Each time the Reset Log loads, three checks run and show a warning banner when they find something (expand a banner for the list):

• Failed-verify spike — an IP address with 30 or more failed code verifications in the last hour, which can indicate a credential-stuffing attempt.
• Repeat resets — a user with 3 or more successful resets in the last 30 days.
• Reset → privilege change — a successful reset followed within 5 minutes by a group-membership or privilege change recorded in the Audit Log, which can indicate account takeover.

CSV export

Click Export CSV above the table to download the log with the current filters applied. Recovery addresses appear masked in the export, as they do on screen.

25.6 Security notes

• Cloudflare Turnstile protects the first step (entering the email or phone). The student must pass the check before the lookup runs.
• Rate limits (per IP address, over a rolling 10 minutes): about 30 lookups; 2 code sends per IP and per reset session (a third request within 10 minutes is refused); about 10 password-set attempts. Over the limit, the portal asks the student to wait and try again.
• Lockout — set on the Self-Service page under Security policy: Code length (default 6), Code TTL (default 600 seconds), Max verify attempts (default 5) and Lockout (minutes) (default 30). Reaching the maximum wrong codes ends the reset session and logs the attempt as Blocked; an IP address that reaches four times the maximum is blocked for the lockout period.
• Masking — recovery channels are masked in the public portal, the Reset Log and its export. The full value is never shown to the student.
• Retention — Reset Log entries are kept for 1 year by default. Change it under Log retention on the Self-Service page: presets from 90 days to 7 years, or any number of days from 1 to 3,650.
• OnboardConnect never stores the new password. It is sent straight to the reset connection and is not kept afterwards.

25.7 Troubleshooting

"Setup will not enable"

The portal can't be enabled until it has what it needs; the Cannot enable self-service yet banner lists what is missing. Check that a Reset connection is chosen (with its OU lines filled in for an on-prem connection), that at least one messaging channel is on with its SMTP or Twilio connection selected, and that the reset connection has the matching recovery email or phone attribute.

"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 on the Self-Service page (Portal status).

"Code never arrives"

1. Confirm the recovery email or phone is actually present on the student's directory record using Directory 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 Password Reset Log entry for the attempt: open it to see its status and detail; a Failed entry shows the reason the code could not be sent.
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 Microsoft Entra Connect with on-prem authoritative and route Password Reset to Microsoft Entra ID without password writeback enabled, the next directory sync will overwrite the new password with the old on-prem hash. Either enable password writeback in Microsoft Entra Connect, or pick the on-prem agent connection as the Reset connection on the Self-Service page.

"A privileged user can reset through the portal"

The portal accepts an identifier from anyone; eligibility comes from where the lookup searches. For an on-prem reset connection, check the connection's OU lines on the Self-Service page and move the privileged account out of those OUs (or narrow the OUs). If no OU is listed, the lookup searches the Agent's whole base DN. For a Microsoft Entra ID reset connection there is no OU scope — see 25.3.4.

26. Internal Forms

Internal Forms let your team collect records inside OnboardConnect and feed them to workflows. An administrator designs a form in Form Management; staff in the allowed roles fill it in (or import many records at once from a CSV); every entry appears under Form Submissions, where it can be searched, filtered, edited and traced to the workflow runs that used it. Both pages are in the sidebar's Forms group.

26.1 Permissions

Admins have every permission. Operators can submit, view and edit; Viewers can submit and view. Each form can also be limited to specific roles (Allowed roles); with no roles selected, every role can use it.

26.2 Form Management — designing a form

Go to Form Management → New form. Give it a name and description, choose the roles that may use it, and add fields. Field cards can be collapsed and expanded (Collapse all), and the preview shows the form as people will see it (Show hidden fields includes the hidden ones). Each field has a label, a key (the column name workflows see, generated from the label), a type, optional help text, and options:

• Types — Short text, Long text, Number, Email, Date, Dropdown, and Checkbox (stored as true / false).
• Required — the form can't be submitted without it.
• Hidden — not shown on the submit form; set by staff who can edit submissions, or by workflows. A new submission gets the field's default value.
• Default value — the value a new submission starts with when the field is left empty.
• Show in list — show the field as a column in the Form Submissions table (on by default). The submission drawer always shows every field.
• Dropdown options — one per line. Write Label | value to show people a friendly label while storing a different value, for example Staff | OU=Staff,OU=People,DC=company,DC=edu. A line without | is both label and value. Labels appear in the submit form, the list, the drawer, the filters and the workflow editor's Form Read / Form Update pickers; workflows receive the value in the field itself, and Form Read can also pass the chosen option's label as <field>_label (26.4).

Renaming a field's key after submissions exist leaves older values under the old key. To stop using a form, archive it: it no longer accepts submissions or imports, and every submission and its workflow history is kept. A form with submissions can't simply be deleted — you choose to archive it or to delete the form together with all of its submissions. A form that a workflow still uses can't be deleted; remove it from the workflow first, or archive the form.

The form's Workflows section — trigger settings and the workflows using the form — is described in 26.5.

Forms on the home page

People who can view forms see a Forms section on the home page Overview: active forms, submissions in the last 7 days, submissions awaiting processing (not yet read by any workflow) and processed, plus a row per form with its totals, its last submission and the workflows that run on it. The Analytics tab charts form submissions over the last 30 days (days in UTC) with a per-form breakdown. A submission counts as processed once a workflow's Form Read has read it.

26.3 Form Submissions

Pick a form to see its submissions with who submitted each one and when; the columns are the fields marked Show in list. Use New submission to fill the form in.

• Search & filter — search all fields, filter on any field (or Submitted by / Source) with is, is not, contains, does not contain, starts with, ends with, is any of, is none of, is empty or is not empty, limit by date, and sort newest or oldest first. Dropdown filters list the options by label.
• Collapsible panel — collapse the search & filter panel to a one-line summary of what is applied.
• Remembered — your filters, sort, page size and panel state are remembered per form, along with the last form you viewed. They are kept in your browser, so they are per user and per device.

Open a submission to see all its values, edit them, and review its History:

Editing your own entries. People with only the Submit permission see a Your submissions list and can open and correct their own entries — the visible fields only; hidden fields stay as they are. Staff with Edit submissions can change any submission, including hidden fields, and delete submissions.

Import (Edit submissions) adds many records at once from a CSV file: map the CSV columns to form fields, validate to see any rows with problems (reported by CSV line number), then import. Only CSV is accepted — an Excel file is rejected with a reminder to use File → Save As → "CSV UTF-8 (Comma delimited)" in Excel and upload that. Whether an import starts workflows is set on the form (26.5).

26.4 Using forms in workflows

1. In Connections, add an Internal Form connection (no credentials needed; see 8.10).
2. In a workflow, add Form Read (Forms group): choose the connection and the form, and add conditions (for example processed is false; dropdown and checkbox fields offer their values). It outputs one row per matching submission. Max rows (Options) sets how many submissions one run reads — 1 to 1,000, default 1,000; the rest are picked up by the next run.
3. In Form Read's Output section, tick the fields later actions need (see below).
4. Add the steps that act on the records (create accounts, write to the SIS, notify…).
5. Add Form Update to write back to the same submissions — for example set processed to true, or use + Field… to insert {{column}} from an earlier step (such as the username a create step produced).

Form Read — Output section

• Only ticked fields are passed on. Later actions receive the fields ticked in the Output section. _submission_id, _submitted_at and _submitted_by are always passed, so Form Update and {{record._submitted_by}} keep working.
• Select all ticks every field of the form; Clear unticks them all.
• New Form Read steps start with none ticked. Until you tick fields, later actions see only the three submission fields, and their field pickers list nothing else.
• Older steps. A Form Read saved before the Output section existed still passes every field, and shows an amber note: Nothing chosen yet, so this step still passes every field. Tick the ones later actions need. Ticking any field switches it to passing only the ticked ones.

Dropdown labels in workflows

For a dropdown whose options have labels (Label | value), Form Read offers two fields: the field itself holds the stored value, and <field>_label holds the label of the chosen option. With the option Staff | OU=Staff,OU=People,DC=company,DC=edu, role is OU=Staff,OU=People,DC=company,DC=edu and role_label is Staff. Field pickers list them as Role (value) (role) and Role (label) (role_label). Tick role_label in the Output section to use the label in a later step — for example in a Transform template or a SIS write. (If the form already has a field whose key is role_label, no extra label field is added.)

26.5 Starting workflows from a form

Open the form in Form Management. In its Workflows section, two settings (saved with the form) choose which new entries start the workflows that run on it:

• Start workflows for each new submission — every entry made in the portal starts them (on by default).
• Start workflows after an import — an import starts them once when it finishes, not once per row (off by default).

Below them, Workflows using this form lists every workflow that reads or updates the form (or runs on it without a Form Read step on it), with a Run on new entries switch for each — the same setting as Run when a form is submitted in the workflow's settings. A disabled workflow is flagged Disabled — won't run. Save a new form first, then add a Form Read step on it to a workflow.

Turn on Only the submission that started this run in Form Read to process just the new entry (a manual, scheduled or import-started run then reads nothing). A workflow that is already running isn't started again — the submission's history shows Workflow not started — and its next run picks the new entries up.

26.6 How-to: staff & faculty accounts

Slate feeds student accounts; for staff and faculty, HR or a department can submit a form and a workflow creates the account in the right OU with the right rules. Example for on-prem Active Directory:

1. Rule sets. In Provision Rules, add a rule set Staff (and Faculty if their rules differ) — Copy of Students is a quick start. Set each one's username format, password policy and groups; with Fields from set to the form below, group rules can use its fields (e.g. CN=Staff-{department},OU=Groups,DC=company,DC=edu).
2. Form. In Form Management, create Staff account request with First name, Last name, Department, and a required Role dropdown whose values are the OUs:

   Staff | OU=Staff,OU=People,DC=company,DC=edu
   Faculty | OU=Faculty,OU=People,DC=company,DC=edu

   Add a hidden checkbox processed (default false) and a hidden username text field.
3. Connection. Add an Internal Form connection if you don't have one.
4. Workflow. Create a workflow:
   • Form Read on the form, condition processed is false. In its Output section tick First name, Last name, Department and Role (and role_label if a later step should show Staff / Faculty).
   • On-Prem Create — Target OU → OU Source From a field (per record), OU Field = Role (value) (role); Provision Rule Set → Chosen by a field, Field = role — the dropdown's options are listed by label (Staff, Faculty); pick the Staff rule set for Staff and Faculty for Faculty; Username Source From provision rule (recommended), mapping {first_name} / {last_name} to the form fields; Display Name from a Transform Fields step or a form field.
   • On-Prem Security Groups with Source From provision rule (recommended) and the same rule-set choice — groups are not set on the create step.
   • Form Update — set processed to true and username to the created username with + Field….
5. Trigger. Turn on Run on new entries for the workflow in the form's Workflows section (or run it on a schedule). Each request then shows the run's outcome in its History.

27. Email Templates

Email templates are the messages an Email Notify step sends. Manage them under Settings → Email Templates; pick one in the step and set who it goes to.

27.1 Starter templates

Every tenant starts with these. Edit them freely; your copies are never overwritten.

27.2 Variables

In the template editor, the Available Variables panel lists the variables you can use. It starts collapsed — click its header (Show) to open it, then click a variable to insert it at the cursor in the subject or body.

27.3 One email per run, or per person

A template that uses only run-level variables (tenant, workflow) sends one email per run. When the template uses a person or form variable (record, account, submission), or the step's To contains a field such as {{record.email}} or {{record._submitted_by}}, the step sends one email per record that reached it. Records without an address are skipped and named in the step's result; the step sends at most 500 emails per run.