Summary
Problem Statement
The Glific form-builder does not accept or auto-create payload variables beyond a specific default, causing issues in handling user inputs.
User Expectations
The user expected to be able to add custom payload variables (e.g., fname, grade, schname) for better handling of form submissions.
Actual Outcome
The additional payload variables are discarded by the Glific flow-builder when submitted, leading to inaccessible form responses in BigQuery.
Error Messages
No specific error messages were reported, but it was noted that added variables "disappear" upon submission.
Reproduction Steps
- Publish a WhatsApp form with fields (e.g.,
fname).
- Configure the form in a Glific flow.
- Attempt to add custom payload variables to the form's JSON.
- Submit the form and observe that extra payloads do not appear in the results.
Additional Details
- The user had previously linked external documentation to support their case.
- They identified a workaround but expressed frustration regarding limitations in the existing Glific functionality.
- The discussion included various questions about the Glific platform's capabilities and its alignment with Meta's messaging policies.
Source
Original message
Artifacts:
Published: teacher_registration_with_optin
Draft: teacher_registration_with_optin_payloads
HSM with the published: teacher_registration_1
HSM in a flow: flow
Now while the form 'works' in the materialized sense that the end-user sees the form and enters details, its contents are inaccessible to Glific unless added to the on-click-action payload. Even BQ doesn't store these: fname, grade, and schname. Any help is appreciated.
Full thread transcript
usurpesh: Artifacts:
Published: teacher_registration_with_optin
Draft: teacher_registration_with_optin_payloads
HSM with the published: teacher_registration_1
HSM in a flow: flow
Now while the form 'works' in the materialized sense that the end-user sees the form and enters details, its contents are inaccessible to Glific unless added to the on-click-action payload. Even BQ doesn't store these: fname, grade, and schname. Any help is appreciated.
Glific AI doc bot (bot): Hey! Thanks for sharing all the links—this helps a lot.
- In Glific, WhatsApp Form answers are captured only when the HSM (with the form button) is immediately followed by a Wait for response node; then you can reference each answer in the flow using the form’s Field Names (visible in the form builder under the “Field Names” tab) .
- For BigQuery, each submission is stored in whatsapp_forms_responses with the full raw_response JSON; you can extract fields like fname, grade, schname using JSON_VALUE on the exact keys shown in the Field Names view (see the example SQL pattern in the docs) .
- Quick checks: ensure you’re using the Published form in your HSM, place a Wait for response right after the HSM in your flow, and confirm you see new rows for this form in whatsapp_forms_responses after a test submission .
If you already have the Wait for response in the flow and still don’t see rows for teacher_registration_with_optin, let me know and I can loop in support.
Glific AI doc bot (bot): Was this helpful in resolving your query? Or do you need further support?
Glific AI doc bot (bot): Thanks for letting us know! <@&983219484091383888> has been notified and will assist you shortly.
sangeetamishra._91310: <@1038832836414808124> - Can we get on a short 10-15 min call to undertsand this issue better ?
usurpesh: Sure, when's a good time?
sangeetamishra._91310: We can connect at 2 PM if that works for you ?
usurpesh: Sorry. Could we do some time after 4 please?
sangeetamishra._91310: Sure
usurpesh: Thank you. Sorry, I'm stuck with something so couldn't do 2 or sooner.
sangeetamishra._91310: No worries
sangeetamishra._91310: <@1038832836414808124> - https://meet.google.com/sxt-kobd-ius?hs=122&authuser=0 here is the link to connect now
sangeetamishra._91310: <@1038832836414808124> - Thanks for the time on call as discussed allow me time till Monday will check this internally and get back.
sangeetamishra._91310: <@1038832836414808124> I checked the Form JSON https://amaatra.glific.com/whatsapp-forms/433/edit
The payload doesn't has all the variables hence it isn't giving the desired result.
Please check this documentation about JSON structure.
Now as you can't edit the JSON you will have to create a new one.
usurpesh: Thank you, Sangeeta. The issue really wasn't about not knowing that the payload needed those additional variables - it is that Glific's flow-builder automatically discards/rejects anything added beyond ${data.optin}. Try adding, say "full_name": "${form.fname}" to form, and apply changes, and let me know if that works.
And this automatic payload rejection by Glific is what I was trying to explain the other day over the call.
Also, it is frankly from the official documentation you've linked that I'm building the flows and bringing them into Glific - and - that's also how I knew it was the payload that was the problem.
usurpesh: This is a fully valid json according to the documentation you've shared. Simply copy and dump it into any of the example flows they've provided in the page here - there's no invalidation. However, try adding the same into Glific's flow-builder and watch the additional payloads disappear.
usurpesh: I'm pretty certain it's something to do with the conditional part, but I can't really place my finger on why exactly it should reject the additional parameters. It could just as well return empty/null/variable_name even if unassigned when the condition fails.
akanshaa19: let me take a look <@1038832836414808124>
akanshaa19: this is because the glific form builder doesn't support the If component right now, so any fields nested inside an If get dropped from the submit payload. instead, use the visible property on each field bound to ${form.optin} the field shows only when Opt In is checked, and it round-trips correctly through the builder.
akanshaa19: here is a sample JSON for your use case
usurpesh: Hello Akansha, thank you for this - my bad I couldn't respond sooner. While I did try this before, the reason to not adopt this was that OptIn cannot be made false and have the flow simply terminate. Because the second screen's contents are required, the user cannot simply proceed without entering the details despite not wanting to OptIn, and thereby feel stuck, without explicit knowledge of 'simply closing the form'.
I have chosen to go with the alternative idea of simply not having OptIn as part of the Form. Feel free to consider this specific query closed.
Additional general questions out of curiosity:
-
Why are Flows implemented via HSM, even though Meta treats them as free-form messages? Not being able to dynamically assign variables in Flows/Forms and workarounds are quite painful.
-
Given Meta’s unpredictable template category reassignments to MARKETING, are there any planned fixes to prevent forms/Flows from incurring additional MARKETING template costs when used between flows?
-
An updated bulk template submission CSV that supports Glific Form buttons?
-
And, is it possible to submit a Flow JSON to Meta directly and retrieve the corresponding Meta Flow ID and use them to submit the HSM template (for now, to bypass the builder limitations)?
TL;DR - query closed;thanks for the json: not the fix that can be used, but a fix nevertheless; hoping for an updated WhatsApp Flows implementation.
Summary
Problem Statement
The Glific form-builder does not accept or auto-create payload variables beyond a specific default, causing issues in handling user inputs.
User Expectations
The user expected to be able to add custom payload variables (e.g.,
fname,grade,schname) for better handling of form submissions.Actual Outcome
The additional payload variables are discarded by the Glific flow-builder when submitted, leading to inaccessible form responses in BigQuery.
Error Messages
No specific error messages were reported, but it was noted that added variables "disappear" upon submission.
Reproduction Steps
fname).Additional Details
Source
Original message
Artifacts:
Published: teacher_registration_with_optinDraft: teacher_registration_with_optin_payloadsHSM with the published: teacher_registration_1HSM in a flow: flowNow while the form 'works' in the materialized sense that the end-user sees the form and enters details, its contents are inaccessible to Glific unless added to the on-click-action payload. Even BQ doesn't store these:
fname,grade, andschname. Any help is appreciated.Full thread transcript
usurpesh: Artifacts:
Published: teacher_registration_with_optinDraft: teacher_registration_with_optin_payloadsHSM with the published: teacher_registration_1HSM in a flow: flowNow while the form 'works' in the materialized sense that the end-user sees the form and enters details, its contents are inaccessible to Glific unless added to the on-click-action payload. Even BQ doesn't store these:
fname,grade, andschname. Any help is appreciated.Glific AI doc bot (bot): Hey! Thanks for sharing all the links—this helps a lot.
If you already have the Wait for response in the flow and still don’t see rows for teacher_registration_with_optin, let me know and I can loop in support.
Glific AI doc bot (bot): Was this helpful in resolving your query? Or do you need further support?
Glific AI doc bot (bot): Thanks for letting us know! <@&983219484091383888> has been notified and will assist you shortly.
sangeetamishra._91310: <@1038832836414808124> - Can we get on a short 10-15 min call to undertsand this issue better ?
usurpesh: Sure, when's a good time?
sangeetamishra._91310: We can connect at 2 PM if that works for you ?
usurpesh: Sorry. Could we do some time after 4 please?
sangeetamishra._91310: Sure
usurpesh: Thank you. Sorry, I'm stuck with something so couldn't do 2 or sooner.
sangeetamishra._91310: No worries
sangeetamishra._91310: <@1038832836414808124> - https://meet.google.com/sxt-kobd-ius?hs=122&authuser=0 here is the link to connect now
sangeetamishra._91310: <@1038832836414808124> - Thanks for the time on call as discussed allow me time till Monday will check this internally and get back.
sangeetamishra._91310: <@1038832836414808124> I checked the Form JSON https://amaatra.glific.com/whatsapp-forms/433/edit
The payload doesn't has all the variables hence it isn't giving the desired result.
Please check this documentation about JSON structure.
Now as you can't edit the JSON you will have to create a new one.
usurpesh: Thank you, Sangeeta. The issue really wasn't about not knowing that the payload needed those additional variables - it is that Glific's flow-builder automatically discards/rejects anything added beyond ${data.optin}. Try adding, say
"full_name": "${form.fname}"to form, and apply changes, and let me know if that works.And this automatic payload rejection by Glific is what I was trying to explain the other day over the call.
Also, it is frankly from the official documentation you've linked that I'm building the flows and bringing them into Glific - and - that's also how I knew it was the payload that was the problem.
usurpesh: This is a fully valid json according to the documentation you've shared. Simply copy and dump it into any of the example flows they've provided in the page here - there's no invalidation. However, try adding the same into Glific's flow-builder and watch the additional payloads disappear.
usurpesh: I'm pretty certain it's something to do with the conditional part, but I can't really place my finger on why exactly it should reject the additional parameters. It could just as well return empty/null/variable_name even if unassigned when the condition fails.
akanshaa19: let me take a look <@1038832836414808124>
akanshaa19: this is because the glific form builder doesn't support the If component right now, so any fields nested inside an If get dropped from the submit payload. instead, use the visible property on each field bound to ${form.optin} the field shows only when Opt In is checked, and it round-trips correctly through the builder.
akanshaa19: here is a sample JSON for your use case
usurpesh: Hello Akansha, thank you for this - my bad I couldn't respond sooner. While I did try this before, the reason to not adopt this was that OptIn cannot be made
falseand have the flow simply terminate. Because the second screen's contents arerequired, the user cannot simply proceed without entering the details despite not wanting to OptIn, and thereby feel stuck, without explicit knowledge of 'simply closing the form'.I have chosen to go with the alternative idea of simply not having OptIn as part of the Form. Feel free to consider this specific query closed.
Additional general questions out of curiosity:
Why are Flows implemented via HSM, even though Meta treats them as free-form messages? Not being able to dynamically assign variables in Flows/Forms and workarounds are quite painful.
Given Meta’s unpredictable template category reassignments to MARKETING, are there any planned fixes to prevent forms/Flows from incurring additional MARKETING template costs when used between flows?
An updated bulk template submission CSV that supports Glific Form buttons?
And, is it possible to submit a Flow JSON to Meta directly and retrieve the corresponding Meta Flow ID and use them to submit the HSM template (for now, to bypass the builder limitations)?
TL;DR - query closed;thanks for the
json: not the fix that can be used, but a fix nevertheless; hoping for an updated WhatsApp Flows implementation.