Test Public Pages
Check public forms, booking pages, payments, checkout, and signing before sharing.
Test public pages before customers use them. This catches broken links, incorrect branding, unavailable times, payment configuration issues, and missing required fields.
Always test public pages outside your signed-in workspace flow. A private browser window gives the closest view of what a customer will see.
Test Checklist
For every public page:
- Open the link in a browser where you are not relying on workspace navigation.
- Review branding, page title, and customer-facing text.
- Complete the expected action.
- Confirm the result appears inside Agiled.
- Confirm any expected email, payment, booking, workflow, or notification.
Also test the exact link you plan to share, including the custom domain when one is configured. Do not rely only on the internal preview.
Test with realistic data that is clearly marked as test data. This makes it easy to find generated contacts, appointments, orders, payments, documents, and workflow runs during cleanup.
Test Forms
Submit a test response and confirm it appears under the form submissions.
Open the created or updated record too. A form can submit successfully while the field mapping, notification, or workflow result is still wrong.
Use realistic but clearly marked test data, such as a customer name that starts with “Test.” Fill every required field and at least one optional field that maps to CRM, deals, tickets, or custom attributes. This proves both required-field validation and downstream mapping.
If the form is embedded on your website, test the embedded page separately from the direct Agiled link. Website layout, cookie settings, security headers, or theme scripts can affect the embedded experience even when the direct link works.
Test Booking
Select an event type, pick a time, complete the booking, and confirm the appointment appears in Agiled and any connected calendar.
Check timezone, location, custom questions, confirmation email, and add-to- calendar link. If payment is required, test the payment step as well.
Test at least one available slot and one unavailable edge case, such as a busy time or a day outside the booking window. Confirm the public page hides blocked times and writes the final appointment to the expected host calendar.
Test Payments and Checkout
Confirm products, totals, taxes, gateway settings, success pages, and created orders or payments.
For invoices and estimates, test PDF download, attachment download, payment methods, signature requirements, and status changes after the customer action.
Use the gateway’s test mode or a low-risk internal checkout when possible. After payment, compare Agiled status, gateway dashboard status, customer receipt, and any generated invoice or order. These four places should tell the same story.
If you cannot use gateway test mode, use a controlled low-risk purchase and refund process approved by finance. Do not run live payment tests without a cleanup plan.
Clean Up Test Data
After testing, delete or clearly mark test submissions, appointments, orders, payments, and documents so reports and workflows are not polluted.
If the test triggered workflows or customer-facing emails, check the related records before deleting anything. You may need the test run history to confirm that the workflow behaved correctly.
Launch Evidence
Keep a short launch note with the tested link, test date, tester, browser, resulting Agiled record, and any payment or workflow evidence. This gives support a starting point if customers report issues after launch.