Grouping and Bundling
What this does
Combine multiple Quik! forms into a single package so your users fill out, save, and sign them as one unit. Most real-world workflows involve more than one form: account openings often need a primary form plus a beneficiary designation plus a transfer authorization. This guide shows the recipes for the most common bundling scenarios.
For the underlying mental model and terminology (Form Group vs Form Group Instance vs duplicate form), see Concepts > Form Lifecycle > Form Groups and Instances.
When to use this
Reach for this guide when you need to:
- Generate two or more different forms for the same person in one workflow.
- Add the same form multiple times in one package (multiple transfers, multiple beneficiary forms).
- Generate forms for multiple accounts or family members in a single call.
- Manage saved Form Groups programmatically (create, edit, delete via API).
Before you start
You should have:
- An understanding of the underlying concepts (Form Group, Form Group Instance, duplicate form). See Concepts > Form Lifecycle > Form Groups and Instances.
- The Form IDs you want to bundle together.
- Your account subscribed to the libraries each Form ID belongs to. See Library Subscription.
Recipe 1: Multiple forms in one package
The simplest bundling case. Put multiple Form IDs in QuikFormID, separated by commas. One set of prefill data applies to every form.
{
"QuikFormID": "12,449,5659",
"HostFormOnQuik": true,
"FormFields": [
{ "FieldName": "1own.FName", "FieldValue": "John" },
{ "FieldName": "1own.LName", "FieldValue": "Doe" },
{ "FieldName": "1own.H.Email", "FieldValue": "john@example.com" }
]
}
The user gets one form viewer URL showing all three forms in order. The same 1own.FName value prefills on every form that has that field.
Use this when: one person is filling out several different forms in the same workflow (a single account opening that requires multiple forms).
Recipe 2: Add the same form twice (duplicate forms)
Put the same Form ID in the list more than once. Quik! renames fields on the duplicate copies so the data does not collide.
{
"QuikFormID": "12,12",
"HostFormOnQuik": true,
"FormFields": [
{ "FieldName": "1own.FName", "FieldValue": "John" },
{ "FieldName": "1own.FName-1", "FieldValue": "Sally" }
]
}
The first copy of Form 12 prefills with John. The second copy uses the -1 suffix and prefills with Sally.
|
Copy of the form |
Field name |
|---|---|
|
First copy |
|
|
Second copy |
|
|
Third copy |
|
|
Fourth copy |
|
Use this when: the same transaction needs two or more copies of one form (multiple transfers into a single new account, two beneficiary forms for different beneficiaries on the same account opening).
Recipe 3: Multiple sets of forms for different people (Form Group Instances)
Separate sets of forms with dashes in QuikFormID. Each set is a Form Group Instance with its own prefill data. Within each instance, comma-separated Form IDs work as in Recipe 1.
Scenario: a household opens three accounts at the same firm in one workflow.
{
"QuikFormID": "6996,2,2-6996,12-2,12",
"HostFormOnQuik": true,
"FormFields": [
{ "FieldName": "1own.FName", "FieldValue": "John" },
{ "FieldName": "1own.FName-1", "FieldValue": "Sally" },
{ "FieldName": "1own.FName-1000", "FieldValue": "John Jr" },
{ "FieldName": "1own.FName-2000", "FieldValue": "Mary" }
]
}
This generates:
|
Instance |
Form IDs |
Suffix for fields |
|---|---|---|
|
Instance 1 |
|
no suffix for first copy, |
|
Instance 2 |
|
|
|
Instance 3 |
|
|
Each new instance increments the suffix by 1000. Duplicates within an instance increment by 1 from the instance's base.
Use this when: one package needs to cover separate transactions or different people. Common patterns: households opening multiple accounts, multiple beneficiaries with separate paperwork, joint accounts where the same people swap roles across forms.
For DocuSign signer configuration across instances (so the same person signs once instead of multiple times), see Concepts > Form Lifecycle > Form Groups and Instances.
Recipe 4: Manage saved Form Groups via API
If you set up Form Groups in the Quik! Forms Enterprise Manager and want to manage them programmatically (create, update, delete, add or remove Form IDs), use the Form Groups Services API.
Endpoint
https://websvcs.quikforms.com/rest/formgroups/v1000/
Authentication requires Master credentials for the customer account. Regular user credentials will not work.
Create a Form Group
POST /customers/formgroups
{
"Name": "Pershing IRA Opening Package",
"Description": "Standard forms for opening a Pershing IRA",
"FormIds": [12, 449, 5659],
"IsPublic": true
}
IsPublic: true makes the group available to every user in the account. false keeps it scoped to the creator.
List, retrieve, update, or delete Form Groups
|
Method |
Endpoint |
What it does |
|---|---|---|
|
|
|
List every Form Group in the customer account. Response includes a |
|
|
|
Retrieve one Form Group by ID. |
|
|
|
Edit name, description, or visibility. |
|
|
|
Remove the Form Group. |
|
|
|
Add Form IDs to an existing group. Body: |
|
|
|
Remove Form IDs from a group. Body: |
Use a saved Form Group in a generation
Form Groups themselves are not passed directly into execute/html. Instead, retrieve the Form Group's Form IDs (via GET /customers/formgroups/{id}) and pass that list of IDs into QuikFormID when generating.
Limits and best practices
Keep packages under 120 pages
Quik! recommends generating no more than around 120 pages in a single bundle. Larger bundles still work, but they can take minutes to render in the browser and produce a poor user experience.
For reference, a 500-page bundle in Quik!'s internal testing produced an 11 MB HTML file, took 90 seconds to generate, and took an additional 4 minutes to load in the form viewer. Above 120 pages, plan to split.
Splitting large household packages
If you need to bundle forms for an entire household across many accounts and the page count would exceed 120, generate each account's forms as a separate package instead of one giant Form Group Instance package:
- For each account in the household, call
execute/htmlonce with that account's Form IDs and prefill data. - Present the user with separate links to each account's form viewer.
- Have the user complete and e-sign each account in turn.
- After all accounts are signed, use a unique identifier (a HouseholdID you assign) to retrieve all the signed PDFs together and combine them for delivery or archive.
This is also a friendlier UX. Users get a clear list of accounts to work through instead of one massive form viewer.
Use saved Form Groups when the same package recurs
If your users frequently generate the same combination of forms, set up a Form Group once and reference its Form IDs every time. Less typing, fewer mistakes, and changes in one place propagate.
Pitfalls
- The first Form Group Instance has no suffix on its field names. Only the second instance and beyond use suffixes (
-1000,-2000, etc.). Adding a suffix to the first instance will fail to prefill. - Duplicate suffixes (
-1,-2) and instance suffixes (-1000,-2000) are different things.-1means "second copy of this form within this instance."-1000means "first copy of the form in the second instance." Confusing them lands data on the wrong form. - Adding too many forms causes slow renders. The Quik! Forms Engine does not time out on large packages but the user's browser may. 120 pages is the recommended ceiling. Split larger sets into smaller packages tied together by a HouseholdID or similar.
- Form Groups Services API requires Master credentials. A regular user account cannot create or edit Form Groups via the API even if they can do it in the Forms Enterprise Manager UI.
- Form Groups are not the same as Form Group Instances at API call time. Form Groups are a saved list of Form IDs managed in the Enterprise Manager. Form Group Instances are a runtime mechanism for separating sets of data in one package. They share a word but solve different problems.
- Invalid Form IDs in a comma-separated list are silently dropped from the response. If you bundle
12,449,99999and Form 99999 does not exist in your library, the response returnsFormIDs: "12,449"without flagging the missing one. Compare requested vs returned IDs if you need certainty.
Related articles
Continue with these articles to understand the related concepts and workflows:
-
Form Groups and Instances — Learn the core concepts behind grouped forms, duplicate forms, and separate data sets.
-
Fields and Field Names — Review how field names change when the same form or role appears more than once.
-
Roles and Role Prefixes — Understand how roles keep people and entities separate across a package.
-
Send Direct to DocuSign — See how grouped packages move into a DocuSign signing workflow.
