Appearance
UIEngine Integration Flows — Plain English
Last updated: March 18, 2026
Short, non-technical descriptions of how key parts of the system work. Written for nonprofit staff who are not developers.
1. What happens when a member purchases a membership (Stripe → UIEngine → LGL)
The member pays on the website using Stripe. When Stripe confirms the payment, it notifies UIEngine (this can happen when checkout finishes or when the payment itself succeeds—whichever path applies for that purchase). UIEngine records the payment, then fulfills what was bought: for a membership it creates or renews the membership, may set up a new account or password link, and sends confirmation email. It does not send everything to Little Green Light in one lump; it adds separate tasks for things like the payment, the membership, and any classes or events in the same cart. A background process runs about every 30 seconds, works through those tasks in order, and updates LGL so the CRM gets the gift and membership details without staff doing each step by hand.
2. What the LGL sync does and when it runs
LGL sync copies information from UIEngine to Little Green Light: people (constituents), memberships, payments (as gifts), class and event enrollments, and family add-on relationships where those apply. It does not change UIEngine; it only pushes data out. Tasks are queued whenever something important happens (for example a purchase, membership change, or enrollment). The same background process that runs about every 30 seconds also handles other kinds of queued work (see messaging below). LGL-related tasks are handled one at a time within each batch so the CRM is not overwhelmed and records stay consistent. Staff can see the queue and retry failed items in Admin under Sync.
3. What the WordPress sync does and when it runs
There are two different WordPress flows. Import / refresh: Staff can pull data from the existing WordPress site into UIEngine on demand—user profiles, membership status and dates, and class or event enrollments from past orders—usually for migration or catching up. That only runs when someone starts it from Admin (by person or bulk), not on a daily clock. Updates back to WordPress: If a member’s UIEngine account is linked to a WordPress user, creating or renewing a membership can queue work to push membership status back to WordPress, and the system may also refresh that status right after a successful purchase so the website profile stays in step.
4. What the messaging/campaign system does end-to-end
Staff create email campaigns in Admin: pick a template, choose who receives it (for example everyone in a specific class, all members at a certain level, all users, or hand-picked people), and edit the subject and body with simple placeholders like first name. The system counts how many people match. Send now queues a background job; schedule for later saves the campaign until a checker runs about every five minutes, then queues it the same way. The actual sending runs in small batches so mail systems are not flooded, and each send is logged (sent or failed). Marketing-style audiences skip people who have turned off marketing email and skip test accounts. Campaign status (draft, scheduled, sending, sent) shows in the campaigns list.
5. What the difference is between donations and payments
Payments are money tied to something specific you sell: a membership, a language class, an event, a conversation club, or similar. The system knows what was purchased and ties the charge to membership, enrollment, or event registration as appropriate. Donations are voluntary gifts—often with suggested amounts and wording you set in Admin—and are routed in LGL toward your donations fund and campaign instead of program or membership funds. Someone’s cart can mix membership, classes, and a donation in one checkout; Stripe still collects one payment, but behind the scenes the system and LGL treat the types of income differently for reporting and CRM.
6. How mid-semester enrollment and proration work
When a member enrolls in a class after it has already started, the system calculates a prorated price based on the sessions remaining rather than the full term price. For example, if a class has 10 sessions and a member joins after 3 have passed, they pay for 7 sessions. The proration math (sessions total, sessions remaining, proration factor) is stored directly on the enrollment record so that LGL sync, confirmation emails, and admin views all reflect the adjusted amount. Staff can also override the proration cutoff per enrollment if needed. The prorated amount is what Stripe collects and what shows in the cart and order summary.
7. What semesters are and how they relate to classes
A semester is a time period for organizing classes (for example Spring 2026, Fall 2026). Each class offering is tied to one semester: “Spanish A2” in Spring is one catalog item, and “Spanish A2” in Fall is another, so history and enrollment counts stay correct per term. Semesters can have optional display and registration windows (start and end dates)—when those are set, they control when classes in that semester appear and when people can register. Staff create semesters in Admin, attach classes to them, and can copy classes from an older semester into a new one to speed up term setup.
7. What inventory tracks
Inventory is a live view of capacity for things that have a limit: classes, events, memberships, and similar offerings. For each item it shows how many spots are filled, how many remain, waitlist if you use it, and a simple status such as full, filling up, or plenty of room. Staff use the inventory page in Admin to see what is full, what still has seats, and where waitlists are building.
8. What the testing suite does (time machine, scenarios, cleanup)
The testing area in Admin is meant for non-live environments. You must turn on test mode before using the tools; that blocks real outbound email to members and helps mark data as test-related. The time machine shifts “today” forward or backward so you can exercise renewal reminders, due dates, and other calendar-driven behavior without waiting weeks. Scenarios (for example test memberships) create predictable situations to walk through purchases and sync. Cleanup removes test data when you are done; database reset loads a fresh test dataset when you want to start over. A typical renewal-email check is: create scenario data → use the time machine → run cleanup (or reset) when finished.