ZC_FileZC_File0, ZC_File1, ZC_File2, etc.| Scenario | Fields Created | Attachments Received | Result |
|---|---|---|---|
| Setup for single attachment | ZC_File |
1 attachment | ✓ Works perfectly |
| Setup for single attachment | ZC_File |
2+ attachments | ✗ Only captures first attachment |
| Setup for multiple attachments | ZC_File0, ZC_File1 |
2 attachments | ✓ Works perfectly |
| Setup for multiple attachments | ZC_File0, ZC_File1 |
1 attachment | ✗ Captures NOTHING - looks for ZC_File, not ZC_File0 |
ZC_File ← Captures single attachments
ZC_File0 ← Captures first of multiple attachments
ZC_File1 ← Captures second of multiple attachments
ZC_File2 ← Captures third of multiple attachments
...and so on
ZC_File0, ZC_File1 naming convention should be smart enough to handle ANY number of attachments, including just one. If only 1 attachment is received, it should be captured by ZC_File0 automatically, rather than requiring a separate ZC_File field.
Alternatively, use the new field type that allows "multiple file upload" which can dynamically capture 1-to-N attachments without requiring pre-defined field quantities.
Can this be addressed in a future update?
The current implementation forces developers to choose between:
|
1. Reliability Creating redundant fields to handle all cases |
2. Clean design Having fewer fields but risking data loss |
We shouldn't have to make this choice.
Community Input Requested: Has anyone else encountered this issue or found a better workaround?