Since 2017, Candid has offered a simpler way to help people improve their smile. The company delivers custom clear teeth aligners straight to your door for 65% less than braces. Thanks to optical laser scans and advanced 3D printing, Candid’s board-certified orthodontists can remotely supervise treatments so customers get to skip time-consuming office visits.

Teledentistry is a new service so Candid’s ability to build trust and educate customers on the benefits of using clear aligners to straighten teeth has been a vital part of their success. Candid’s “Am I a Candidate” survey provides a safe space for potential customers to determine whether clear aligners are right for them. Optimizing Candid's “Am I a Candidate” survey on Formsort has increased sales by over 30%.

Client challenges: Off-the-shelf solutions lacked flexibility and security, but custom coding wasn't scaling with their demand

Cosgrove’s team of product managers, designers, and engineers are in charge of Candid’s entire online experience. While their existing survey worked, their home-grown infrastructure lacked flexibility, making testing new variants a cumbersome and engineering-intensive endeavor. 

Co-founder and CIO, Lilla Cosgrove, explained “We chose to build our survey ourselves because in 2017 there weren’t off-the-shelf tools that would give us the flexibility to express our brand and to deeply integrate into our technology stack while ensuring the security we required as a healthcare business.” She felt they needed a more flexible and robust solution to better personalize their customer experience and to evolve alongside their increasingly complex marketing initiatives.

Formsort solutions: High fidelity branding, seamless integrations, and simple deployments

Still there were critical concerns with using a third party solution. The team at Candid started by evaluating existing off the shelf tools and found them underpowered.  With the exception of Formsort, there weren’t offerings that allowed Candid to stay on brand, maintain a consistent data set of events and answers, and integrate with the rest of their tools. 

The survey was the starting point for the majority of their customers so it needed to be perfectly in sync with the broader look and feel of the Candid site. “We were very happy to see the incredibly fine-grained control of the UX available in Formsort” said Candid Senior Product Designer Ethan McDonald. “Even the smallest details like button shadow and our progress bar were re-creatable.”

Staying in control of customer data and maintaining an accurate single source of truth was of paramount importance to Candid’s engineering team. The onboarding survey needed to integrate into the broader marketing tech stack so that their carefully curated customer journey could be instrumented and actioned upon. 

Integrating with complex business logic was among the companies must have features. Candid uses a customer’s zip code as one input to surface the best treatment option available; if a customer is not within the service area of a Candid studio where their teeth can be easily scanned, they are instead presented with the option to order an impression kit. To achieve this type of complex decisioning-based on customer answers, Formsort integrates seamlessly with Candid’s backend APIs to handle custom conditional logic.

After migrating the survey to Formsort, the Candid team began experimenting with survey variants to optimize for conversions. They tested several different variants including earlier branching of respondents based on problem type, changing up the look and feel of the form, and introducing testimonial pictures and video. 

All of this testing could be done directly on the Formsort platform freeing up the engineering and product team to tackle other issues. Dan McClean, Director of Growth Product, explained “we push most of our users through a survey flow which tells them whether they are candidates for our company's product. We've been able to improve conversion rate through the survey substantially, and have increased sales at least 30% by optimizing the survey experience. Formsort makes it easy to make changes and push them live to customers.”

Results: Faster learnings, time savings and better conversion rates

Candid’s approach to ramping up Formsort involved splitting traffic between their existing in-house infrastructure and the same content on the Formsort platform. To compare the two systems, Candid measured kit and studio booking completion rates for eligible customers. 

Formsort meaningfully lowered the activation energy required to improve their survey. Since getting started with Formsort, Candid has averaged over 27 published revisions per month ranging from small copy changes to larger content restructuring.

In the initial ramp-up phase Candid saw a meaningful lift in conversion rates as a result of the performance and stability of the Formsort platform; the content-controlled experiment resulted in an unexpected double digit percentage improvement in completions versus the original in-house infrastructure.

With a rapidly expanding business, Candid's engineers needed to reserve their bandwidth for feature development, not form maintenance. As marketing requests for form updates started to become a burden, Formsort empowered the marketing and product team to make those changes themselves, saving countless engineering hours.

In the initial ramp-up phase Candid saw a meaningful lift in conversion rates as a result of the performance and stability of the Formsort platform; the content-controlled experiment resulted in an unexpected double digit percentage improvement in completion versus in-house infrastructure. Candid’s approach to ramping up Formsort involved splitting traffic between their existing in-house infrastructure and the same content on the Formsort platform. To compare the two systems, Candid measured kit and studio booking completion rates for eligible customers. 

Head of Product

We've been able to improve conversion rate through the survey substantially, and have increased sales at least 30% by optimizing the survey experience. Formsort makes it easy to make changes and push them live to customers.

See how Candid leveraged Formsort's design, integration, and testing tools to increase sales via their "Am I a Candidate?" survey.

How Candid increased sales by 30% with better patient onboarding

So, your business needs to build a form. It may seem like a simple request, but behind every feature request is a product manager who is responsible for defining where the requirements of the feature begins and ends. Forms are a crucial part of web applications, but the effort of building and maintaining them is often overlooked in an initial scope. 

As businesses scale and more niche services come online, many of their form requirements can't be satisfied by third party low code form builders. This often brings product managers and developers to a crossroads where they have to decide to trade functionality for ease, or start down the path of custom coding their forms. 

With 32% of an average developers time being spent on existing code maintenance and testing, it's important to plan for how these tradeoffs will have a downstream impact on servicing your web presence as your business grows. While building a form may seem like a one-off project for a development team, often there are hidden costs that come with the decision to build and maintain your own web forms. 

Whether building an HTML or react form, there are several requirements for product managers and their development teams to consider. Will you use controlled or uncontrolled components? Do you need to bring in design elements that aren't used elsewhere in your application? What kind of responsive behavior is necessary for the best UX? 

It may just seem like a sign-up form, but as the barrier between your customers and your business, form building has to be approached thoughtfully to ensure success. If low code form builders aren't an option for you, make sure you are asking your team these questions before committing to custom coding your forms.

Design is iterative in nature and form design is a science itself. On average a mid-size company will need 6-7 weeks to finalize the design for a new UI. And that's pending any stakeholder or client reviews. Structure, labels, interactive elements and, most importantly, seamless branding, are all considerations that a UI designer has to factor in when creating a form that's effective and human. 

If the design team comes back with requirements for dropdowns, images, or other custom elements they think are necessary to make the form most attractive to users, developers may have to bring in new elements that they don't use in other parts of the application. While configuring these elements doesn't have to be overly time consuming, especially if you are using a design framework like Material UI, product managers and developers should consider how these requests impact their velocity in regards to requested changes or non out-of-the-box design elements. 

Often low code form builders have the advantage when it comes to iterative design. Themes and styles are stored so they can be edited on platform by non-technical team members, shared for review and collaboration, and can be applied to any new form. You should consider how custom your design needs are to avoid over-designing your forms.

It's not enough to build a stunning web page anymore: that experience needs to be seamless for users across browsers and devices. Users switch between devices regular so being online 24/7 is an opportunity that organizations can't afford to miss. When custom coding web forms, you need to make sure that your forms are compatible with all user's devices and browsers. 

This often means condensing, simplifying or re-approaching the design of your web form. Your development and design team will have to consider how to minimize white space, avoid unnecessary zooming or scrolling, progress states, and automatic form field fills. You may even have your own mobile application, as 44% of organizations with more than 1,000 employees do, and it may not be written in the same language as your web app, creating a second stream of work to manage.

To further complicate the issue, often forms are embedded in other apps' UI as part of a partnership or programmatic advertising strategy. There may be limitations within these third party complications that require you to rethink how your form works in those environments. The Snapchat browser’s inability to support swipe actions in embedded forms is a good example of UI constraints. If swiping is a component of your web form and embedding that in Snapchat is a requirement from your marketing team, you will need to have a different version of your form that does not rely on that swipe element.

These considerations are additional investments that can push the timeline of releasing what seemed like "just a sign up form" back by weeks, if not months. 

As product managers start to dig into form requirements the "must haves" list grows long, and what seem like a "nice to haves" could be the difference between growth and falling flat. A form on its own is not that useful if you can't use the inputs to take actions for your users. Many of these actions can be automated, as long as you have the right dependencies integrated. Often these dependencies are must haves that are necessary for an organization to close operational gaps between their sales, marketing and support teams. 

From data collection and validation to third party integrations, the more complex your business operations, the longer it will take to custom code forms with all of the key dependencies necessary to get the most out of every submission. It's necessary for product managers to document all required dependencies and make sure their developers have the right familiarity to hit the ground running as you put these features into development. 

With over 2 million websites built in react, including Facebook and Instagram, it's likely that your modern web application is using these form libraries or some type of Javascript to render fluid, interactive web pages. In addition to form libraries, developers also need to leverage events and Hooks for DOM and state management when building web forms to display form components and store submissions.

Form components are the records of data that display your form fields and are generally editable fields. They are your text boxes, radio buttons and dropdown selections that make up the UI of your form. In addition to designing a form your users will love, product managers will need to work with their development teams on how they will display forms on the web and handle form submissions. 

It's key to decide if you want to use controlled components, uncontrolled components, or a hybrid. Controlled components handle data inputs within the component itself to serve as a single source of truth for that form element. Uncontrolled components behave more like traditional HTML forms by storing each data input element in the DOM. 

Each come with their tradeoffs: controlled components are most often used in production, but when building, testing on uncontrolled components can be useful for avoiding bugs and inadvertent logic loops. Controlled elements require an event state for every element, so it's important to consider your applications specific form needs before committing to either path.

Everyone's felt the frustration of completing a form only to get an error on submission. Using validation to avoid this and ensure the data is compatible with the form before sending it to the server will save a lot of headaches. 

Having client side form field validation applied to standard fields such as passwords, emails, phone number phone formats and so on has become a must have for any online form.Losing a potential customer over a simple error, like the 1-2% of users who misspell “gmail”, can become frustrating if your forms are not built with validation in mind. Be sure to plan for any value constraints, character limits, error messages and so on. 

In addition to common built-in form validations, some applications require user criteria to determine the next steps. For example, Candid's "Am I a Candidate?" form immediately gives users the results about their eligibility for their aligners. Depending on the industry, there can be necessary validations around address or payments that require libraries or calls to third party applications to check the information, such as FedEx for delivery or Stripe for holding funds. 

These dependencies can be as simple as requiring authorization for a login page as part of your form, or as complex as needing to meet strict compliance standards. If you operate in the healthcare industry, baking in HIPAA compliance as part of your form security will be a must have. Or maybe your organization's data governance policy is GDPR compliant. Considering how you will encrypt your forms for PHI, PII and basic account information requires consideration.

From detecting common misspellings to planning for deeply baked compliance, these are units of work for engineering teams to do for a single component, becoming expensive problems. 

In addition to how your forms render and submit components, where and how you store form data element inputs matters. You will need to consider what actions are triggered by form elements when a user presses "Submit" on any web form and the methods of sending them to your server. There can be additional dependencies here too depending on your current database schema: do the fields being collected exist in your database already? If not, where will you put them, and what table relationships need to be established? 

Most importantly, you need to ensure that your form data is secure when passing it to your server. It is imperative that the data you send to the server is sanitized. HTML forms are the most common failure points for server attacks. Avoiding common form security issues requires putting in user guardrails like avoiding special characters, limiting the amount of data a user can send, and creating sandbox or other URLs that can be used to access files and data to avoid single points of failure. 

Generally it’s important to think about security as a layer, not something that is done at a component level. When you custom engineer secured, hashed or compliant forms, it’s necessary to go the extra mile and thoroughly QA to ensure that the effort has been made to make the right fields secure. Low code platforms can be secure by design by acting as a data collection but not storage partner, but if you are custom coding your forms, make sure your server and database architecture is equipped to handle these security threats before you build.

The average public SaaS company uses about 350 integrations, and the average SaaS startup (of the 1000 fastest growing) uses about 15 integrations. Chances are, your organization is relying on one or more third party services to stay competitive. 

While it's more and more common for these third parties to offer APIs, developers know that a third party API is not necessarily an off-the-shelf solution for their app. There is often a lot of documentation to comb through as well as considering how this new service fits into their infrastructure or any code refactoring that may be required. 

Additionally, your organization's marketing team may be dependent on the engagement data they measure from Google Analytics to make informed decisions. While the data collected in your forms will be stored in your database, you run the risk of creating a silo if you cannot expose the form submission information to the right parties efficiently. For transparency, it's essential to account for any required integrations when scoping the effort for building forms into your web applications. 

Growth requires rapid experimentation and iteration, functions that have become a natural extension of a product manager's responsibilities. In an era where we have the data required to react in real time, feature development is never truly finished, with modern product managers championing hypotheses testing and quality of life improvements, especially on more mature platforms. This means that your forms are living documents that needs to be revisited and optimized, and often quickly, as new insights or assumptions need to be gleaned and validated. 

As a product manager, adjusting your roadmap repeatedly to account for form iterations and experiments can become a burden on your developers. Rather than focusing on technical debt or ideating the next innovative project, they are making design or form updates, with all the testing and deployment steps that come with that, even if for a single request. 

For product managers tasked with enabling cross-functional communication and incorporating stakeholders, marketing or support requests for form variants or updates can cause a disconnect. When you are dedicating resources to custom coding web forms, as a product manager it's your responsibility to account for the downstream impacts on other functional areas as well as the future velocity of your development team against these competing priorities. 

No one wants to receive a support ticket to update a line of copy or remove, add, or adjust a single field when they are working on other projects. While bugs are an expected part of development, fielding requests for minor changes is often not an efficient use of a developer's valuable time. 

When electing to custom code and host your web forms, these engineering changes need to be scheduled, planned, approved, and weighed as a priority against your roadmap, often in perpetuity. These processes can slow down marketing experimentation and result in missed conversion or engagement opportunities.

Unfortunately, modifications to forms are inevitable. While you may plan to build for edge cases, users often manage to "break" things in ways that you couldn't anticipate until the form is live. What happens when someone abandons a form and returns later, did you develop it to include hold states or to pass recorded data? What happens if the same form is open in two tabs of the same browser? 

It's normal for questions like these to arise after your form is live and to remember that if you are opting to custom code your forms, building the form may take a few days, but the iterations will take time and expertise. 

Edge cases aside, as your business expands, adds more services and learns more about your customers, it's extremely likely that your forms will need to evolve with your business. Whether you've added a new validation type or decided to change your value proposition entirely, your forms will need to follow suit.

As your forms are accessed by more users, patterns will start to emerge in the data that inspire marketing hypotheses to test. A/B testing is an effective framework for validating assumptions about what improvements can have an impact on key metrics and results. Using a control group, sets of users will be shown different versions of a web page and the lift will be measured to determine the most effective version.

While this is a great practice for business operations, it has similarities to the problem with form fields. These experiments will require adjustments to your form, often multiple variations at a time, in quick succession to impact decision making. To arrive at an optimal conversion rate, A/B testing can remove biases to help you decide when you’ve moved the needle enough. 

This is also assuming that you already have an A/B testing mechanism in place for creating and measuring control groups. Many smaller organizations have to balance resources and growth carefully, meaning A/B testing may be discounted until it is a necessity. Due to unique needs, many organizations actually homebrew A/B testing platforms that can become a maintenance burden as you scale. If you haven’t started implementing a similar framework, or have spun up your own internally, consider how you will manage variants to prove the expected results and continuously optimize to get there when deciding to custom code your web forms.

Take the two examples above on likely needs for form iterations, and what you get is a need for a lot of deployments. While continuous integration and delivery are standard in most organizations, testing and deploying form code is an investment. When you opt to custom code your web forms, the content and the implementation will remain closely coupled. 

Server dependencies can create complications, especially when integrating form components the first time. There are many ways to get components onto public servers and tradeoffs to consider: do we need new vendors, and what is required for approval? Who will handle SLAs for sensitive data? If your web forms have many moving parts, server dependencies such as operating systems, receiving components, build processes, and security groups become microservices within your org quickly that can cause complications in your deployment pipeline, as well as ongoing devops.

Although it's unlikely that merging these form changes will take the industry average of 8 hours, if you have several successive iteration requests, or any failures in your pipeline, that time can add up against a developers often already limited bandwidth. When custom coding forms, depending on how many applications or form variants you have, it's important to consider what team or individual will "own" these services moving forward to avoid the time sinks that come with this kind of regular maintenance.

Now that you know more about what goes into scoping, building and maintaining custom forms, your head might be spinning. Depending on how many forms your business needs, it's clear that these features can require a big investment of ongoing development resources, especially if you want to move quickly. When researching solutions, product managers need to be thorough about evaluating all of the available options before starting down a resource heavy path that may require future pivots or cause conflicts with their product strategy. 

The purpose of a form is to engage and convert users, sometimes requiring quick reactions to evolving behavior or new feedback. From the design to technical requirements, the data integration or authorization dependencies, and the ongoing maintenance that is necessary to accommodate experimentation, forms can quickly become a burden on your development team if product managers don't consider all of these elements early in the planning process. 

While low code platforms can meet emerging businesses needs for a time, their evolving requirements often outpace the services capabilities. Formsort was built to fill the gap between simplified form management and complex business logic. If you're standing at the crossroads of needing more from your form builder and heading down the path of custom development, we're here to start building with you.

Are low code form builders not working for your business? Here's what product managers need to know about the hidden costs of building and maintaining forms before you start to custom code a solution.

Low code or custom code? A product manager’s guide to tradeoffs

Until you publish a flow, it is only visible to other users of your organization in the Formsort studio. Once you publish a flow, it becomes immediately accessible under a URL in the flow.formsort.com domain.

While your flow is fully functional under this domain, we do not recommend using it in production, as users may be confused by the root domain not matching the content.

If you'd like to embed Formsort within an existing page, there are a few different approaches.

Upon publishing, you will see an option to copy a javascript snippet that will load the flow. This is the simplest approach - by copy pasting this snippet into your HTML, the formsort flow will load.

If you are a non-technical user that just needs to put a flow within another page, such as embedding a form within Unbounce or integrating the flow with a Squarespace page, this approach should suffice.

If your flow ends in a redirect, the containing page will be navigated to the redirect URL once the flow is finalized.

The @formsort/react-embed package on npm allows to embed Formsort within React applications, and comes with Typescript type annotations. The flow parameters are passed as props to the component.

~~~jsx~~~
import EmbedFlow from '@formsort/react-embed';

//...

<EmbedFlow
  clientLabel='formsort'
  flowLabel='onboarding'
  variantLabel='main'
  embedConfig={{
    style: {
      width: '100%',
      height: '100%',
    }
  }}
/>

Compared to the javascript snippet, the React embed will load more quickly, as the loading code will be part of your javascript bundle and the flow can immediately start loading.

In addition to loading and displaying the flow, you will have access to callbacks for flow lifecycle events, such as when a step or the flow itself is completed.

If you don't use react, @formsort/web-embed-api is a pure-javascript embed option.

Internally, Formsort loads as an <iframe> and communicates with your page using a protocol using window.postMessage. web-embed-api wraps that communication with an event emitter that you can use more simply.

If you'd rather not host a page just to present a form, you can configure your DNS to point to formsort servers, and we will serve your flow at that domain.

When you add a domain to formsort, we will issue a star certificate for that URL pattern. For example, if you add flow.example.com, we will issue a certificate for *.example.com. After domain verification, you will be able to add other subdomains to point to Formsort.

For performance, your DNS records will actually point to our CDN provider, Amazon CloudFront, which then loads your flows from our origin servers.

Once configured, domains may be pointed to one of your flows. That flow (or specific variant of a flow), will be served at the root of that domain.

Other flows and variants that you have created will be accessible by explicitly providing their flow parameters in the URL. For example, you could load a variant called beta of a flow called cancellation by specifying it in the URL:

flow.example.com/flow/cancellation/variant/beta

Note that unlike when using the bare flow.formsort.com domain it is not necessary to specify your client name when using a CNAME, as only you can publish flows on your own domain

If you create multiple domains, one of your domains will be selectable as the default domain. The domain that is chosen for this purpose will be used as the base for all other flows in your account, if those flows do not have another domain pointed directly at them.

Overview of domains, embeds, and form hosting.

We've seen, across countless organizations, a similar pattern of the life of a product form. Regardless of where you are along the lifecycle, it's useful to be mindful of it.

So you need to collect some information from your users, and are setting out to build a product form. In all likelihood, it's something that's a key part of your user experience: perhaps even the first conversation you have with a user, in the form of a sign-up flow.

Forms seem like they'd be easy to build. After all, html has supported the <form> element for ages, and you have access to some developers, so why not let them build? Particularly since your form feels pretty unique, given your organization's unique product or pitch, and the branding aesthetic you have in mind to support it, it seems that nothing off the shelf would work for this.

You get together with your designer, a couple of stakeholders, and in a couple of hours come together with a user flow - a handful of post-it notes on a wall, some presentation slides, and some copy to go alongside a design that's likely inspired by work that others have done.

You're feeling confident, this should be a quick project and then you'll be able to move on.

Since this probably isn't the only thing your company has going on, you might end up needing to wait a few days or weeks for developers to get involved. But once you're at the top of the list, you hand off the project to the developers, you provide them the content, design, as well as some wise guidance like "we'll want to test changes to this in the future" and "make sure that it's responsive", and "we might want to make parts of this dynamic".

The developers are initially excited about the project. Unlike working on backend work, or cobbling together marketing pages, this feels like something that will directly speak to users. Plus, most everyone on the team has done some variation of forms in the past, and it seems to them that they'll be able to string together a few off-the-shelf libraries to put the flow together, and they'll be done. Wise engineers will also take a little time to architect a small framework for managing form state, and it's off to building.

However, as the project is underway, they start encountering hiccups. The many existing form frameworks and validation libraries don't play well together. There's a question of what should be done on the frontend, and what should be done on the backend. You're not really sure how the flow will evolve in the future, so you eschew making complicated schemas in favor of down-the-line flexibility. Everyone starts to get a feeling of re-inventing the wheel, poorly.

As many complicated technical issues of state management, data integrity, and logic get encountered, the short initial estimates for the project timeline result in those issues being punted down the line, and some "nice to haves" get cut out as being "out of scope". Business counterparts get told: we'll be able to fix things and change them later, since we designed the system well.

After a few weeks, it's good enough, you slap in google analytics to understand what's going on, and you're ready to go live!

Everyone's excited! Your onboarding flow is live. You catch a couple of small issues but you're pretty happy with it overall, so you take a little bit of time to celebrate.

Ah… missed a couple more things, just some low-hanging fruit.

Once you're live for a few days, little issues start popping up. Not quite unexpected, but there seem to be a lot of them. Some executives complain it doesn't work on their home computers. Developers forgot to make the back button work. The inputs seem to jump around in some cases. It's hard to read some of the pages on smaller screens.

At first it seems like a lot of low-hanging fruit. But there's a lot of this low hanging fruit. You fix a few of the first problems, but then it gets hard to address the bigger issues, since the basics work after all, and inevitably the form project gets deprioritization since the company has other things to work on. After all, you're trying to run a business, not a form company.

Seems like we'll need to address some of that technical debt.

After a couple weeks, you start running into some bigger problems with the forms. You realize that it's pretty difficult to actually analyze the flow, and you'll need to redo the marketing events. Some customers start the flow, go away, and then come back later, and their experience is broken. And then a junior developer makes a small change to the flow logic, and accidentally breaks the ability to complete the signup. Minor changes seem to take on the complexity of performing surgeries, if surgeries were performed in the dark.

There's a mounting need to address some of the technical debt, but there's no time to. After all, the project is done, and you've moved on.

Turns out we didn't really understand the user.

Once the data starts coming in, and you hear from real users, it turns out, the meeting a few months ago where we sketched out the user journey wasn't entirely correct. Perhaps your product isn't suitable for a single-shot purchase, and people are re-visiting your site multiple times before converting. Or you've realized that your idealized persona of a "user" is actually dozens of different user types -- some, very experienced, technical users who just want to breeze through, while others need a bit more handholding. People care about different things, but you're putting them all in through the same flow.

People want quicker iterations. Can't we can we just test things? But the engineering time isn't focused on the onboarding flow -- changes are risky, and take a bunch of time as tests must be rewritten, logic tested manually.

Yikes, this form is a mess, as is the team that built it.

While all this is happening, the world around doesn't stop. Your organization's design and brand evolves over time. Marketing wants to try new experiences with new customer segments. Browsers, devices, and the web platform evolve in parallel. Data people want to consume more data in different ways. People start setting up landing page tools, experiment frameworks, and analytics providers, hoping that something will be a magic bullet to make the forms work well.

Organizational discontent starts to brew. Engineers don't want to make small changes to the flow, because they're risky, and they'd rather build more interesting things. But they don't have the time to do the big project of building a full out forms CMS. Executives wonder why they can't have the latest shiny thing. Marketing folks lament how difficult it is to do personalization, or just improve conversion in the first place. Product people are trying to make everyone happy, but can't.

Okay, we need to build it again, hopefully we'll get it right this time.

You end up re-building your whole onboarding. Your initial assumptions weren't correct, but this time you'll get it right. You have another series of meetings, you re-prioritize the form project, and you end up spending a couple of months building a new thing, while keeping the old thing running, making sure to also transition smoothly from the old to the new, now that dozens of poorly-documented downstream integrations and dependencies exist.

This takes way longer than the first time. And while you've addressed some of the problems with the v1, the v2 comes with its own problems. You still don't have the institutional buy-in to build a proper forms platform (after all, you're not a forms company) so you end up with another cobbled-together second system.

Guess this stuff is harder than it seemed...

By this point, you realize that this is going to be an ongoing process. Now, you've staffed a whole team of top engineers, product managers, and data people to work on your form flow. That quick project you thought would be done in a few weeks is now a line item in your staffing budget. It's costing you hundreds of thousands of dollars, yet it feels like it's moving slower than ever before.

Build and iterate on your form flows quickly.

Integrate directly with your data and analytics.

Extend when needed, use best practices when you don't.

Stay confident with schemas and logic validation.

Don't worry about keeping up to date on web trends.

Focus on the content of your user journey, not how it's made.

Forms are the center of many technical and organizational problems

Often, you'll already know something about a responder before they even start filling out your form flow.

Avoid repetition and personalize the responder's experience by pre-filling form answers. Formsort supports three methods of passing data into form flows:

The easiest way to pre-populate forms with existing answers is to pass them directly in the URL, using the query string. The query string appears at the end of the URL's pathname (but before a hash). It begins with a ?, and is followed by a number of key and value pairs, each separated by an & and joined with a =.

Example URL     https://flow.formsort.com/client/formsort/flow/onboarding/variant/main?email=hello%40formsort.com&name=Fil#0
Host            https://flow.formsort.com
Pathname        /client/formsort/flow/onboarding/variant/main
Query string    ?email=hello%40formsort.com&name=Fil
Hash            #0

For each value that you wish to set, use the Answer variable name as the key, and the value you wish to set as the value.

Safe and easy generation of the query string

The query string is part of the URL, and its components need to be url-safe. Characters list spaces, ampersands, and others cannot appear in URLs, and so need to be escaped. This is why in the above example hello@formsort.com actually appears as hello%40formsort.com: it has been percent-encoded.

If you're generating the URL to redirect to in javascript, make sure to use the encodeURIComponent() method on each part that you're encoding. Similar functions exist for other languages.

If you're using the Formsort preview window, you can also set answers and see the generated URL using the Set answers... dialog.

If you aren't seeing your answers pre-populate, check your browser's javascript console. It may be the case that you have typoed the variable name or have formatted the value incorrectly.

There is no single standard for setting multiple values (eg, a select question that allows choosing multiple values). Formsort handles this by allowing you to repeat the answer key.

If you have a variable named favorite_fruits and want to pre-set it to both Apple and Banana, the query string should look like this:

?favorite_fruits=Apple&favorite_fruits=Banana

When adding or editing a domain under which you will be hosting flows, you may set a default query string using the Default URL params field.

This is useful if you want to parametrize a flow based on what URL a responder is accessing it from, without needing to include URL parameters in every usage of that URL. For example, if you have a flow that contains a variable named country, you can set up one domain called fr.example.com with Default URL params set to ?country=France and another domain called es.example.com with Default URL params set to ?country=Spain and those answers would be pre-set when accessing the flows, even if accessing the bare URL without any query string.

Note that default query strings don't actually appear in the URL, but are merged with any query string that does appear in the url. Answers appearing in the URL take precedence over those set in the default.

Consideration: personally-identifying information (PII)

As part of the loading sequence, and before loading any third-party analytics, Formsort strips any values that correspond to semantically-labeled answers (such as responder_email or responder_first_name), or answers that have been marked as Don't send to analytics from the URL.

This is because many third party analytics scripts will happily log the URL of an event, and since the query string is part of the event, you may be sending PII to third parties if the answer were not stripped.

Url modification is an imperfect solution

While the query string approach is the easiest way to pre-populate data into Formsort, there's always a risk of leaking information with URLs (for example, browser extensions that load before Formsort and report which URLs they are loaded on.

When working with particularly sensitive data, we recommend using either cookies or POSTing answers, described below.

Cookies are text data that websites can store in your browser, which your browser sends back to servers, as a way of persisting data.You can use cookies to pass values into Formsort flows.

For security, browsers do not send cookies acrossdomains: flow.formsort.com cannot access or write cookie data on the example.com domain.

This restriction does not apply to subdomains, however: survey.example.com can read and write cookies from the example.com domain just fine.

Enable Read/write in cookie in the schema editor for the answers you wish to read and write using cookies.

Write a cookie, on your root domain, with a key of the variable name and a value of the answer for each answer you wish to pass forward.

If, in the course of filling out the flow, the responder changes their answer for one of the cookie-enabled answers, the cookie will be updated with the new answer.

One of the most secure ways of passing data into a Formsort flow is to POST into the form.

Normally, when you navigate to a flow URL, your browser does a GET request to our servers. GET requests do not have a payload (known as a body): when making a link, the only way to pass information to the receiving page is using URL parameters, as described above. Since the parameters appear in the URL, they are visible to not only the responder but potentially to other scripts or browser extensions that you or the responder has loaded on their flow.

A POST request, on the other hand, has an encrypted body, and is the default way to submit form data in basic HTML. Formsort supports POSTing to the flow URLs as well as GETing. A form like the following would ask the responder for a name answer, then submit it to the Formsort URL. Note that we set the name attribute to match the Answer variable name value we've defined in the flow.

~~~html~~~
<!doctype html>
<html>
  <body>
    <form action="https://flow.formsort.com/client/formsort/flow/test/variant/test-post" method="POST">
      <label for="first_name">Enter your first name</label>
      <input type="text" name="first_name" required />
      <button type="submit">Let's go</button>
    </form>
  </body>
</html>

If you don't actually want to ask questions before redirecting to formsort, that's not a problem: just set all of the answers you wish to pass forward within the value attribute of <input> elements with type=hidden, like this:

~~~html~~~
<input type="hidden" name="first_name" value="Olivia" />

When the containing <form> is submitted, the answers will come along for the ride, just as if the responder has entered them.

Different ways to provide information about a responder ahead of time.

Conceptually, you can think of a table in a columnar relational database such as Redshift as similar to a spreadsheet.

The table's schema determines which columns are present, and what the types the values in those columns should take.

Date              Name              Age
--------------------------------------------------

A database can enforce that dates are formatted as dates, and much more.

When data is written into the table, rows are created, which you can think of as new rows in a spreadsheet.

Date              Name              Age
--------------------------------------------------
12/09/2019        Olivia            4
12/09/2019        Stubby            7

While Formsort flows also have schemas, those schemas can change over time, as new questions are added in order to collect new answers. To prevent needing to update the Redshift database columns every time a new answer is collected, answers are written into a single column, answers, in a data format known as JSON.

JSON allows us to express objects that contain multiple values, which are referenced by their keys. So instead of needing multiple columns for the above examples, the single answers column would contain the values all together.

date              answers
--------------------------------------------------------------
12/09/2019        {
                    "name": "Olivia",
                    "age": 4
                  }

12/10/2019        {
                    "name": "Stubby",
                    "age": 7
                  }             

Note that while every row will have the same columns, not every row might have the same set of keys and values. For example, if we start asking users for their birthday, the answer to that question will only be present in the dataset from that point on.

date              answers
--------------------------------------------------------------
12/09/2019        {
                    "name": "Olivia",
                    "age": 4
                  }

12/10/2019        {
                    "name": "Stubby",
                    "age": 7
                  }

12/11/2019        {
                    "name": "Rosie",
                    "age": 10,
                    "birthday": "02/13/2009"
                  }         

To get answers out of the JSON column, you'd use the standard SELECT statement that you may be familiar with.

~~~sql~~~
SELECT
  answers
FROM
  formsort.answer_set

But if you merely select answers, you'll get a blob of text containing the JSON object, which isn't easy to use for direct analysis:

{
  "name": "Olivia",
  "age": 4
}

{
  "name": "Stubby",
  "age": 7
}

{
  "name": "Rosie",
  "age": 10,
  "birthday": "02/13/2009"
}

To reach into answers you'll want to use a function called json_extract_path_text instead, telling the database which key we want from answers using the second parameter, in this case, 'name'.

~~~sql~~~
SELECT
  json_extract_path_text(answers, 'name') AS name
FROM
  formsort.answer_set

You can also select multiple answers out at once by repeating the fields you'd like to select out.

~~~sql~~~
SELECT
  json_extract_path_text(answers, 'name') AS name,
  json_extract_path_text(answers, 'age') AS age
FROM
  formsort.answer_set

name          age
-------------------
Olivia        4
Stubby        7
Rosie         10

Omitting rows without particular answer values

As mentioned earlier, when new answers are collected in a flow, they will only appear in the answers column from that point on. The behavior of json_extract_path_text is to return the empty string when a value is missing, so we can use that in a WHERE clause to filter out rows where a particular answer is not set.

~~~sql~~~
SELECT
  json_extract_path_text(answers, 'birthday') AS name,
FROM
  formsort.answer_set
WHERE json_extract_path_text(answers, 'birthday') != ''

Sort of a blog

How Candid increased sales by 30% with better patient onboarding

Low code or custom code? A product manager’s guide to tradeoffs

Form deployment options

Pitfalls of building your own form flows

Passing data into form flows

Finding answers inside of Redshift JSON columns