Jenzabar

Meadow's Jenzabar integration follows a standardized, file-based approach deployed across multiple institutions. Meadow provides template scripts (PowerShell) and SQL files that work out of the box or need minimal modification. An experienced Meadow integration specialist guides your IT team through setup.

1. Solution Overview

1.1 What Is Meadow?

Meadow is a modern, mobile student accounts receivable (A/R) and payment solution helping hundreds of colleges and universities resolve more balances and retain more students by automating the entire pre-collections process.

1.2 Implementation Scope

The integration is file-driven, using SFTP to transfer CSV files on a regular cadence, with bi-directional data flow between Jenzabar and Meadow.

Jenzabar → Meadow. Data is exported from SQL stored procedures through scheduled tasks and PowerShell, and sent to Meadow via SFTP with key-based authentication: academic calendar, student data, and charge data.

Meadow → Jenzabar. PowerShell downloads payments from SFTP and posts them to Jenzabar using SQL stored procedures that correctly update student payment and G/L tables.

1.3 Implementation Timeline

Typical implementations complete in 4 to 6 weeks with four steps:

1. Configure networking, DNS, email allow-listing, and SSO.
2. Either self-install the script bundle, or grant temporary remote access for Meadow to complete this for you (preferred).
3. Enable and validate SIS data imports.
4. Configure and validate payment post-back.

2. Data Imports Overview

• Academic calendar data. Academic periods and term start and end dates, used to determine billing timelines and when balances become past due.
• Student data. Demographic and enrollment information used to identify student accounts, communicate with students, and associate payments with the correct record.
• Charge data. Charges and transactions representing student balances: tuition, fees, deposits, financial aid adjustments, refunds, and payments.

3. Scheduled Task Workflows

Each task launches in the context of an AD service account, then uses Kerberos to connect to SQL Server and execute a stored procedure. This avoids storing the AD password in plain text and avoids granting extensive SQL permissions. SFTP is handled by WinSCPnet.dll via assembly binding.

3.1 Extract

Windows Task Scheduler (or another job scheduler) calls Meadow-Export.ps1 with:

• Config file location. Maps each command to a stored procedure and holds SQL and SFTP connection information. A test and a prod config file are typical.
• Command: students (daily), academicCalendar (daily), or charges (15- or 30-minute cadence).

The selected stored procedure runs a query and passes the results to PowerShell, which writes CSV, compresses the file, and uploads it to Meadow's SFTP. Local logs are generated and rotated for each run. Meadow has an alarm that notifies engineers if files stop arriving on the expected cadence.

3.2 Import

Task Scheduler calls Meadow-Postback.ps1 with the same config file, on a 15-minute cadence. PowerShell checks an SFTP directory for unposted payment CSVs, downloads them, and applies them via stored procedures. On success the CSV moves to the posted directory; failed attempts roll back cleanly. Logs for each attempt are posted to SFTP. Meadow has an alarm if files sit for more than 30 minutes in /payments/unposted.

4. Script Installation and Configuration

4.1 Overview

• Create the AD/SQL user and SQL schema.
• Install stored procedures on SQL Server, adjusting school-specific values as needed.
• Choose a working directory for the PowerShell scripts and config files. The VM needs WinSCP installed.
• Supply values to the config files.
• Call PowerShell with parameters (config file and command) on a schedule, typically via Windows Task Scheduler.

4.2 Preliminary Prep

1. Gather config values for CreateMeadow.sql and place them in the script.
2. Find a suitable Windows Server on which to run scheduled PowerShell tasks.
3. Find or create an AD user with a corresponding SQL user to execute the scripts.

4.3 SQL Installation

1. Place all provided files in a folder.
2. Execute lines 1 to 15 of GrantPermissions.sql. Follow the additional instructions in that file.
3. Execute CreateMeadow.sql.
4. Create the four stored procedures by executing MeadowStudentsBaseSelect.sql, MeadowStudentProfilesSelect.sql, MeadowAcademicCalendarSelect.sql, and MeadowChargesSelect.sql.
5. Execute lines 18 to 23 of GrantPermissions.sql.
6. Clone config_sample_ply.json and update the values (next section).

4.4 Config File

Most lines do not need to change. Update:

• SQLconnectionString: server name, and potentially database name. If the server has a valid TLS certificate, set TrustServerCertificate to false (most do not).
• sftp.school_user
• sftp.keyfile (note the double backslashes)
• sftp.keypass
• sftp.root: replace school with the root of your school domain and the environment (stg or prod).

4.5 Testing

In a PowerShell terminal in your working directory, run commands such as Meadow-Export.ps1 -ConfigFile config_ply.json -Command students to confirm each command works (academicCalendar, students, charges). The script supports tab completion.

4.6 Task Scheduling

Students and academic calendar

1. Import the Upload Students, Academic Calendar.xml template.
2. Update the AD account the task runs under.
3. On the Actions tab, update the working directory on the existing "students" action.
4. Save the task and verify it runs. You may need to adjust the path to PowerShell (or use bare powershell.exe).
5. Edit the task and create another action for the "academicCalendar" command.
6. Order the actions so prod runs first, then staging.

Download payments and upload charges

1. Import the Download Payments, Upload Charges.xml template.
2. Update the AD account the task runs under.
3. On the Actions tab, update the working directory on the existing "charges" action.
4. Create another action for posting back payments: -File "Meadow-PostBack.ps1" -ConfigFile "..\config_prod.json", with the working directory set to the \posting-payments subfolder.
5. Save the task and verify it runs.
6. Order the actions as below. Prod runs before staging, and payment post-back runs before the charge export to shorten the round trip before a payment shows in the app.

5. Networking and SSO Configuration

5.1 DNS Configuration

Email records. Meadow sends email through SendGrid. Your Meadow contact provides the CNAME records to add for link tracking, the sending subdomain, and DKIM.

Meadow application DNS. Delegate the pay subdomain to Meadow's nameservers with four NS records. Meadow provides the nameserver values. DNS propagation can be verified with a public DNS checker.

5.2 Email Allow-Listing

In rare cases an email gateway blocks Meadow's messages. If so, your Meadow contact provides the sender IP addresses to allow. If you use an Exchange transport rule that blocks external senders spoofing your domain, add an exception for messages that pass DKIM for your domain.

5.3 SSO Configuration

Meadow supports SAML 2.0. To integrate with your SSO provider:

1. Receive Meadow's SAML metadata. Meadow sends a metadata file containing the Entity ID and public certificate.
2. Configure your SSO provider. Create a SAML integration for Meadow in your provider (Okta, Azure AD, Google Workspace, Shibboleth). Most providers accept the metadata file directly.
3. Configure claims and attributes. Include Email and EmployeeId (mapped to the student ID in your system).
4. Provide federation metadata. Send Meadow your Federation Metadata XML URL or file.
5. Final confirmation. Meadow validates SSO before enabling it for all users.

6. Posting Back Payments

Jenzabar remains the source of truth for student account balances. A payment is not considered complete until it has been successfully posted back to Jenzabar.

1. Payment CSV generation. When a student initiates a payment, Meadow immediately writes a payment file to SFTP with the student ID, amount, and the year and term breakout. A single payment may be split across multiple terms, oldest first, if the student owes for several terms.
2. Payment import to Jenzabar. The scripts in your Jenzabar environment download and apply payments every 15 minutes. See 3.2 Import above.

The post-back script:

• Downloads and parses files
• Invokes stored procedures to insert or update payment data
• Adds all transactions to an audit table
• Logs errors and successes
• Archives processed files to avoid duplication
• Uploads logs to SFTP for transparency

6.1 Testing and Validation

1. Meadow initiates multiple test transactions in the staging environment.
2. The billing office verifies the payments post correctly in Jenzabar.
3. Meadow verifies the payments appear in new charge files (round trip).
4. If issues arise, adjustments are made before moving forward.

6.2 Final Validation in Production

1. Meadow runs a controlled test in production with small payments to real students to confirm payments process, funds post to student accounts, AR and folio code mappings work, and funds reach the school's bank account.
2. The billing office confirms the test transactions are correctly reflected in Jenzabar.
3. Once validated, Meadow is ready to go live.