Limited Production Best Practices

Limited production is the window between UAT sign-off and full launch when your Glide flow is live in production but you control who reaches it. Real applicants, real money, real data landing in your production core. The only difference from full production is volume.

The point is to prove the things staging cannot: money moving through your funding rails, records syncing to your live core, NACHA and document files landing in SFTP, online banking registration on a brand-new account. You want to see each of those work once or twice with a small group before you open the doors.

This article covers what to test and how to structure the rollout for each account opening scope: personal, minor, business, trust, and lending. Your Digital Program Manager (DPM) will build a rollout plan with you before limited production begins. Use this as the starting point for that plan.

How to think about limited production

Start with people who expect issues. The first production applications should come from people who know something might break and will tell you when it does. Then expand to people who are close enough to help in real time. Public applicants come last.

Get money moving on day one. The earliest applications should fund, not just submit. Funding, core sync, and file delivery are the things you cannot verify anywhere else, so do them first rather than saving them for the end.

Expand as soon as the critical tests pass. Each phase exists to check a specific set of things. Once those pass, move to the next phase. Waiting longer does not make the launch safer; it just delays the applications that would have told you about the next issue.

Hold back a flow, not the rollout. If an issue only affects one path (minor accounts, one funding method, one product), keep that path out of limited production, handle those applicants through your existing process, and bring it back when the fix ships. Do not pause everything for one flow.

Watch downstream, not just the confirmation screen. Most limited production findings show up after the application: in the core record, the NACHA file, the SFTP folder, the scheduled report. Assign one person to check those daily.

What counts as a blocker

Every rollout will surface issues. The question is which ones actually stop you. Before each expansion step, walk through the open list with your DPM and sort it.

A blocker is:

1. Any broken flow in the applicant-facing journey (for example, an application cannot be submitted)

2. Compliance-required fields missing, hidden, or not capturing correctly (for example, OFAC, ChexSystems, Reg E disclosures)

3. Authentication or login failures affecting a broad segment of applicants

Not a blocker:

1. UI or cosmetic issues (colors slightly off, spacing, font mismatches) that do not affect functionality

2. Edge case errors that affect a small percentage of flows and have a workaround

3. Non-primary features that were not part of the initial launch scope (a secondary product type, a reporting view)

4. Copy or content tweaks that were not flagged during initial testing

5. Nice-to-have enhancements versus scoped requirements

The key test: if an applicant tried to open an account today, would this issue prevent them from completing it, or put your financial institution at regulatory or reputational risk? If yes, it is a blocker. If the answer is "it's annoying but they'd get through," log it, set a resolution target, and keep moving.

Log every issue in Pylon with the application ID and what you expected to happen. Your DPM will confirm which release the fix is targeted for. Re-test on a new application after the release ships; some fixes only apply to applications created after deployment.

Rollout shape by scope

Personal and minor

Week 1: Project team only. We strongly recommend the first week of a Phase 1 personal and minor limited production be restricted to your project team. This is the first time real money moves and real data flows into your production core, and you want the people opening those accounts to understand that issues may surface and need correcting before anyone else is involved. Use this week to run the critical test cases below, all the way through to your core and your SFTP.

Weeks 2 and 3: Expand to a branch, friends and family, or both. Once the week 1 tests pass, widen the group. A first branch gives you supervised applications: an applicant who completes the flow on their own phone at the desk is a true production application with a staff member right there if anything goes wrong. A friends and family group gives you online-channel applications where you still know who submitted them. Many institutions do both at once.

Week 4: Public launch. Rollout to any remaining branches and publish the link on your website and in your digital channels once the remaining blockers are cleared.

Tactics that make weeks 2 and 3 work better. Every team member in your Glide dashboard has a personal application URL and QR code, available from the three-dot menu next to their name. Print them for desks, or post a single branch QR code, so walk-in applicants can complete the flow on their own device. Applicants often prefer this to reading their Social Security number aloud. For staff who work events, the QR code on a phone lock screen works well.

Critical test cases for personal and minor limited production. Complete these before full production. Each should be verified all the way through to your core, your SFTP, and your downstream systems, not just to the confirmation screen. Plan for your project team to complete all of these test cases in week 1.

1. Who's applying

• New applicant via digital channel

• New applicant via branch channel

• Existing member via digital (pre-Glide login)

• Existing member via branch

• Journey link

• Refer-a-friend, including the GL credit posting

2. What they open

• One of each product type: Savings, Checking, Certificate, Money Market

• Minor account

3. How they fund

• ACH

• Debit card

• Credit card (ensure rejected if your institution does not allow credit card funding)

• Apple Pay

• Google Pay

4. What happens after the account is open

• Joint owner added

• Beneficial owner added

• Debit card order

• Direct deposit switch

• Online banking external registration (fresh application only)

• Online banking SSO

5. What lands downstream (SFTP)

• NACHA file

• Documents for cold storage

• Scheduled reports

Go to full production when any critical test cases from the above list have passed in production, no open blockers remain, and applications from both the branch and digital channels have reconciled to your core and SFTP.

Business and trust

You cannot manufacture a realistic business or trust applicant on demand. A real application needs a real EIN or TIN, a real entity, and real owners or trustees. So the approach here is driven almost entirely by your volume, and for many institutions the right answer is to skip limited production.

Low volume: go straight to full production. If you see a handful of business or trust applications a month, a full launch is already a controlled release. Holding back means waiting weeks for the first application. Launch fully, review each application as it arrives, and line up your first applicants ahead of time: two weeks before go-live, ask your business banking or trust staff to identify applicants who are already planning to open an account and invite them to be first through the flow.

Higher volume: limit first. If you see hundreds of business applications a month, work out the kinks before opening the doors. Two options:

• Roll out to a single branch, with staff walking business owners and trustees through the flow, then expand.

• Use Journeys for controlled production testing. Enable the new business or trust products in Product CMS so they are available in the dashboard but not on your public flow, then create a Journey link scoped to those products and share it only with the businesses or trustees you have selected.

Critical things to verify.

• A business with a single 100% owner

• A business with multiple owners, with every owner landing in your core with the right role

• Each entity type you support

• Beneficial ownership capture

• For trust: each trustee role your configuration supports, the certification of trust upload, and trust-specific disclosures

• Funding and document delivery to SFTP, same as personal

Lending

Lending limited production has one constraint account opening does not: an application submitted to your loan origination system (LOS) in production may trigger a hard credit inquiry on the applicant. That rules out casual test submissions with real credit, and it shapes the plan. Test credit profiles from UAT are for staging only.

The first question to settle with your LOS administrator is whether the LOS can temporarily disable the automated workflows (credit pull, auto-decisioning, processing) that fire when an application arrives from Glide.

If your LOS can pause automated credit pulls. Set the LOS workflow to manual for limited production.

• Weeks 1 and 2: Employees submit applications through the production flow. When each application arrives in the LOS, a staff member verifies that every field mapped correctly, then cancels it before any credit is run. The goal is confirming that applications reach the LOS cleanly and the flow has no critical issues.

• Week 3+: Re-enable automated LOS workflows and focus on real end-to-end applications through assisted channels. Call center staff share the production link with applicants who call in, using co-browse to assist if available. Branch staff walk applicants who come in for a loan through the flow on the applicant's phone rather than taking the application at the desk.

If your LOS cannot pause automated credit pulls. Every production application is a real one, so build limited production around applicants who actually want a loan.

• Week 1: If possible, a few employees who are already planning to apply for a loan.

• Week 2: Branch staff walking real applicants through the online application.

• Week 3: Additional branches or channels, then the public link.

Critical things to verify.

• Every application appears in the LOS with all fields mapped correctly, including vehicle information, co-borrower details, and requested amount.

• Pre-qualification matches your rate sheet: applicants who meet your criteria see the badge, rate, and maximum amount for their tier; applicants who do not can still apply without the badge.

• The activity trail in the staff dashboard shows the pre-qualification outcome and, for applicants who were not pre-qualified, which criteria were not met.

• Status syncing from the LOS back to Glide, if you use it.

• Applicant emails, including denial and document-request triggers.

• The pending error queue. An application in pending error was not submitted to the LOS. Check the queue daily and open a Pylon ticket for each one.

If you are adding the document collection agent, plan it as a short follow-on after the first couple weeks of limited production rather than launching it the same day as lending.

Go to full production when applications are reaching the LOS cleanly, pre-qualification has been checked against your rate sheet, and the pending error queue is clear or every error is ticketed.