Frequently Asked Questions

This page provides practical answers about implementation, support boundaries, learner data handling, and standard operating expectations when using Proximityreels pages and forms.

1. What happens after I submit the discussion form?

After you submit the form, the client-side script validates required fields, prepares a structured payload, and sends the request to the configured endpoint. If the endpoint accepts the payload, you receive a success modal with confirmation text. If the endpoint is unavailable or returns an error status, you receive a failure modal with a short reason. This behavior is intentionally direct so users get immediate feedback and can retry without reloading the page.

2. Why are specific field names required?

The current script normalizes keys from names like form_fields[first_name], form_fields[last_name], and related inputs. Using this exact schema ensures the payload remains compatible with existing processing logic and avoids breaking changes in downstream automation. If field names are changed without updating script logic, payload mapping can become incomplete, causing missing values in external storage.

3. Can the page work without plugin libraries?

Yes. The fallback behavior has been adapted for vanilla JavaScript in core interactions such as menu actions, modal opening and closing, lazy asset activation, counters, and content visibility. This reduces runtime fragility when plugin scripts are unavailable in local preview or static environments. The trade-off is that advanced plugin-only animation timelines are simplified into deterministic UI behavior.

4. What data should users provide?

• First name and last name for proper follow-up.
• Email for response routing and support tracking.
• Phone and area code to support regional outreach.
• Optional message for context, priorities, and timeline.

Data quality improves support speed. Clear project context, expected outcomes, and target audience details help triage requests efficiently.

5. Is form submission secure?

Security depends on deployment context and endpoint configuration. In production, submissions should use HTTPS endpoints, controlled origin policies, and server-side validation. Client-side checks are useful for user experience, but they are not a security boundary. Always validate and sanitize payloads on the receiving service before storage or processing.

6. Why can local preview differ from production?

Local file preview uses file protocol behavior and may block some external resources. Production usually runs over HTTPS with complete asset delivery, CSP rules, and backend connectivity. The local setup is designed to remain functional enough for layout and flow testing, while final behavior should be verified in a hosted environment that mirrors deployment constraints.

7. How often should this FAQ be updated?

Update this page whenever workflow assumptions change: new required fields, endpoint migration, consent updates, identity provider adjustments, or revised response windows. Keeping this text current reduces repeated support questions and ensures policy and behavior remain aligned.