The Wisconsin Masonic Foundation's matching grants program requires a real-time fund balance check against its Ninox database before a lodge is prompted to pay. This integration replaces a manual staff lookup and eliminates the current workflow flaw where lodges mail a physical check before anyone has confirmed funds are available.
This article documents the integration requirements discovered during the [1].
Each lodge has a $4,000 annual matching grant limit (fiscal year: May 1 – April 30). Ninox tracks a running total of funds used per lodge — balances start at zero and accumulate upward; there is no automatic reset at year-end. Staff must manually zero out or roll over balances at the start of each fiscal year.
Current pain point: Under the existing process, a lodge submits its application and mails a physical check simultaneously — before anyone has verified available funds. If the lodge is over its limit, staff must return the check and reject the application. This creates unnecessary rework and a poor applicant experience.
Target state: The online application triggers an automated Ninox fund check. Only if sufficient balance remains does the system prompt the lodge to pay online (CC or ACH). Payment then triggers automated fulfillment.
The online application must capture a lodge identifier that maps unambiguously to a Ninox lodge record. Confirm the exact field name and format used in Ninox (lodge number, lodge name, or internal ID) so the application form can collect or derive the correct key.
On application submission, the integration must:
$4,000 − current_total.Ninox data model notes (from discovery call):
- Balances accumulate from zero; they are not decremented from a $4,000 ceiling.
- There is no automatic fiscal-year reset — the reset is a manual staff action.
- The fiscal year runs May 1 – April 30; any query must scope totals to the current fiscal year window.
| Condition | Action |
|---|---|
| Headroom ≥ requested amount | Proceed: prompt lodge for online payment (CC/ACH) |
| Headroom < requested amount | Block: notify lodge that funds are exhausted; do not collect payment |
After successful payment, the integration must write the approved grant amount back to Ninox so the running total stays current. This prevents double-spending between the time of the check and the time staff would otherwise manually enter the record.
Field to update: the lodge's fiscal-year grant total (confirm exact field name with Erika Miller).
The fund check is gate one of a two-gate flow. Once payment clears, the grant type determines the fulfillment path:
See [2] for the fulfillment automation spec.
The integration does not need to enforce complex eligibility logic. The only program requirement is that the recipient organization be a 501(c)(3) or government agency. This is declared by the applicant on the form; Erika Miller reviews for compliance before final approval is entered into Ninox.
As of the most recent board meeting, the $4,000 limit is unrestricted across all grant types — lodges may allocate it however they choose among the available programs.
| # | Question | Owner |
|---|---|---|
| 1 | What is the exact Ninox field name for the lodge's fiscal-year grant total? | Erika Miller |
| 2 | What lodge identifier field is available in Ninox, and how should the application form collect it? | Mark Hope + Erika Miller |
| 3 | Does Ninox expose an API, or will integration require a middleware layer (e.g., Make/Zapier webhook)? | Mark Hope |
| 4 | Who performs the annual fiscal-year reset in Ninox, and can that be automated? | Erika Miller |
| 5 | What happens if a lodge submits multiple applications simultaneously (race condition on balance)? | Mark Hope |