CodeCanyon Bookly Custom Fields - WordPress Plugin

Guide to Configuring CodeCanyon Bookly Custom Fields for the Booking Form

CodeCanyon Bookly Custom Fields becomes useful when Bookly PRO's standard fields are no longer enough: you may need to ask the client a clarifying question, collect consent, let them choose a preparation option before the appointment, or save an internal note for the administrator. In this guide, we will cover more than installation. We will walk through the practical logic behind it: which fields to create, how to avoid overloading the Details step, how to tie questions to services, where to review responses, and how to quickly figure out why a field is not showing up in the form.

This guide is written for site owners, booking administrators, webmasters, and anyone maintaining a WordPress site. We will focus on working with an existing Bookly PRO setup and the Custom Fields add-on, without purchase instructions, license workarounds, or claims that one field set will fit every business.

The article includes detailed post-installation setup, a practical example for a consulting studio, result verification, a troubleshooting section, FAQ, and a comparison with similar solutions. If you are still deciding whether you need a separate add-on, pay special attention to the sections on limitations, conditional fields, and the difference between appointment fields and client profile data.

What Changes in Bookly After Adding Custom Fields

In its default setup, Bookly collects the client's name, phone number, email address, and an appointment note. For a simple hair salon or consultation service, that may be enough. But as soon as booking becomes part of a real service workflow, you start needing information that should not be buried inside a freeform note: the client's experience level, preferred meeting format, contraindications, group size, membership number, referral source, agreement to rules, or an internal note for staff.

CodeCanyon Bookly Custom Fields adds a structured question layer to the booking form. The administrator creates fields inside the Bookly section, chooses the question type, decides whether the field is required, and can limit it to specific services if needed. The responses become part of the appointment data, so they can be reviewed in the calendar, in the appointments list, and used in notification templates if the selected notification type supports them.

The real value of this add-on is not simply the ability to "add one more field," but control over when the question appears and where the answer ends up. That is what sets it apart from a regular client note: a field can be required, it can offer predefined answer choices, it can be tied to a service, and it can be used in admin workflows.

Where the Client's Responses Appear

According to the Bookly documentation, custom fields appear on the Details step below the standard contact information fields. Once the booking is completed, the entered data is added to the appointment details. An administrator can open the appointment, go to the client data inside the record, and update the responses if necessary. This matters for workflows where the information is clarified later on: for example, the client initially entered "not sure," and a manager later filled in the exact option.

If you use a calendar record template, you can display this data with the generic {custom_fields} code or with the individual field codes shown by the add-on next to each field type. Notifications require a more careful approach: the documentation lists the generic {custom_fields} code for single notifications. For more complex notifications involving multiple appointments, it is better to verify the output with a test email instead of assuming the same code behaves identically in every template flow.

Which Field Types Are Available

The documentation lists a set of field types that covers most practical needs: text field, multi-line text field, text information block, checkbox group, radio button group, dropdown list, numeric field, date field, time field, and captcha. Some types also include additional modes. For example, numeric, time, and date fields can have range limits, while option groups and dropdowns can use a default value.

Your field type choice affects more than the look of the form. It determines data quality. If the question expects one answer, a radio button or dropdown is usually better than freeform text. If multiple answers are possible, you need a checkbox group. If you need a short instruction before the question, use a text information block instead of a fake required field with a dummy answer.

Practical check: if the administrator later has to sort through the answers manually, the field type was probably chosen poorly. Whenever the data needs to be analyzed or processed consistently, use answer options instead of freeform text.

Who This Add-on Is For and When It Is Unnecessary

Bookly Custom Fields works well for sites where a booking is the start of the service, not just a time selection. A dental practice might ask whether the client has been seen before. A fitness studio may want to confirm the participant's experience level. A consultant might ask for a short description of the issue. A training center may collect the participant's age and preferred session format. A service business can tie different questions to different services: an online consultation needs one set of details, while an on-site visit needs another.

The add-on is especially useful when the questions vary by service. The built-in Bind fields to services option lets you show a field only for selected services. That keeps the form from turning into a catch-all questionnaire. A client booking a short consultation does not see questions meant for a long-term program, and someone signing up for a group session does not have to fill in fields that only matter for one-on-one service.

That said, there are cases where the add-on may be unnecessary. If you need to store persistent client profile data that should carry over to future bookings, compare your use case carefully with the Customer Information add-on. If you need file uploads, the Files add-on is closer to that task. If your goal is to change the order of the main form steps, restyle the buttons, or hide system fields, start with Bookly Appearance settings and the main form configuration instead of adding new fields.

Where the Line Is Between an Appointment Question and Client Data

The key distinction is this: a Custom Fields entry belongs to a specific appointment and helps prepare for a specific service. For example, "What is the consultation about?" or "Do you need an interpreter?" are details tied to that specific visit. Client profile data is different. It is information that should outlive a single booking: date of birth, permanent address, client type, internal ID, or long-term preferences.

If you mix these two layers, it becomes hard for the administrator to tell which answers are still current a few months later. The same client may book different services multiple times, and their custom field responses will remain tied to those individual appointments. That is why it helps to create a simple table before setup: which data belongs in the profile once, and which data should be collected again for each service.

When a Field Should Not Be Required

Required fields make sense when the service cannot be delivered or the appointment cannot be accepted without an answer. But every required field on a booking form increases the chance that a client will abandon the process at the details step. If the question helps the manager but is not critical to the booking itself, make it optional or ask it later in a separate follow-up message.

Be especially careful with required settings on conditional fields. The Bookly changelog has included fixes related to required conditional fields and moving to the next step, so the safest workflow is this: test both the hidden and visible states first, then submit the form in a private window, and only then move the setup into your live booking flow.

What to Check Before Installing It on a Live Site

Before installation, it is important to understand that this is not a standalone booking plugin. The official documentation clearly states that Bookly add-ons require Bookly PRO to be installed and active. WordPress.org also notes that add-on installation is not available in the free version of Bookly. So the first check is not "Did the Custom Fields menu appear?" but "Do we have a working combination of WordPress, Bookly, Bookly PRO, and current add-ons?"

You should not begin setup on a live site without a backup. The Bookly changelog recommends making a full backup of the site and database before updating. That is not a formality. Custom fields affect the booking workflow, which means a setup mistake can impact form conversions, notifications, and admin operations.

Quick Compatibility Checklist

Run through this short checklist before installation. It helps separate add-on issues from problems with the base Bookly form:

• Bookly PRO is installed, activated, and the base form already accepts a test booking.
• The main Bookly plugin, Bookly PRO, and all add-ons in use have been updated in sync.
• The site has a backup of both files and the database before the update or installation.
• Employees, services, and a page with the booking form have already been created in Bookly.
• Cache and script optimization are not breaking transitions between form steps.
• The administrator has access to Bookly, Plugins, the calendar, and notifications.

If the base Bookly form is not moving between steps, is not submitting bookings, or is not showing services, fix that first. Custom Fields adds questions to an existing process, but it should not be used as a way to "repair" a booking form that is already misconfigured.

Why It Matters to Update All Bookly Components Together

The Bookly changelog includes a specific warning: if add-ons stop working after a Bookly update, you need to check whether all installed Bookly components are up to date, including Pro and the rest of the add-ons. This matters even more for Custom Fields because it connects to the form, the calendar, notifications, and sometimes other add-ons such as Cart, Packages, Gift Cards, or Files.

In practice, the workflow is simple: make a backup first, then update the main Bookly plugin, Bookly PRO, and the add-ons, then verify that the base booking flow still works, and only after that test the custom fields. If you update only one piece, you may end up with odd symptoms: the field exists in the admin area but does not show on the public form; answers are saved but do not appear in the right template; a condition behaves differently than expected.

Installation and Initial Verification in WordPress

Installation works like a standard WordPress plugin: upload the archive in the Plugins section and activate it. The Bookly documentation describes this path through the plugins screen, after which the Custom Fields section appears in the Bookly menu. If that section does not appear, do not start creating workaround pages or inserting random shortcodes. First, verify the Bookly PRO dependency and the activation status of the add-on.

After activation, run a minimal test. Do not create ten fields right away. Add one optional text field, open the public booking page in a private window, select a service and a time slot, go to the Details step, and confirm that the field appears below the standard contact fields. Then complete a test booking and open it in the calendar or appointments list.

The First Test Scenario

1. Open Plugins and confirm that Bookly, Bookly PRO, and Custom Fields are active.
2. Go to Bookly and find the Custom Fields section in the left sidebar.
3. Create a Text Field with a short label, such as "Consultation topic".
4. Leave the field optional so it does not block your test submission.
5. Save the changes and open the booking form page as a regular visitor.
6. Complete the booking, fill in the new field, and check the appointment in the admin area.

If this minimal scenario works, you can move on to the question structure. If it does not, do not add more complexity. One field with no conditions and no service binding is the best diagnostic test because there is very little there that can conflict.

What Counts as a Successful Installation

A successful installation means more than seeing an active plugin in the WordPress list. Check for four signs: the Custom Fields section is available in the Bookly menu, the created field appears on the Details step, the booking with the answer is saved, and the administrator can see that answer inside the appointment details. If you plan to use notifications, add a fifth sign: the test email contains the correct field code or the general custom data block.

Bottom line: first confirm that the add-on is connected to the form and calendar. Only then should you add conditions, service binding, required settings, and notification templates.

Configuring Custom Fields After Installation

This is the most important section of the guide, because this is where you decide whether the form will be usable. Bad configuration looks like this: the administrator adds every question that comes to mind, makes half of them required, never checks the mobile view, and then wonders why clients abandon the booking. Good configuration starts with the service workflow and the minimum data actually needed.

Open Bookly - Custom Fields. In this section, the administrator chooses a field type, adds it with the plus button, sets the name, description, answer options, and additional parameters. The field order can be changed by dragging the hamburger icon, so it is usually easiest to assemble a draft set first and then arrange the fields in the order that makes the most sense for the client.

How to Choose the Right Field Type for the Question

Start with the question you want to ask. Not with the interface, not with the list of field types, but with how the answer will actually be used by the administrator:

After choosing the type, check the field on the public form. Do not look only at the desktop layout. Test it on a narrow screen as well. A long field description, long answer choices, and several groups in a row may look fine in the admin panel but feel heavy to a client on the booking page.

Required vs Optional Fields

Every field has a cost. A required field should be tied to a real risk: without that answer, the staff member cannot prepare, the service could be delivered incorrectly, or the administrator cannot confirm the booking properly. Everything else is usually better left optional. If you are unsure, start with the optional version and see how often clients answer voluntarily.

If a field is required, write the label in a specific way. A weak label would be "Additional information." A stronger one would be "Enter the participant's age if you are booking a children's session." The client should immediately understand what needs to be entered and why the question is not just empty bureaucracy.

Field Descriptions and Text Prompts

The documentation notes that the description field is visible to the client on the public site. Use that space for a short prompt. For example: "If you already have a membership number, enter it here. If not, leave this field blank." Do not put long policies, legal text, or detailed instructions into one field description. Those belong in a separate Text Content information block or on a dedicated terms page.

Field Order in the Form

Field order affects booking completion. Put the easiest and clearest questions first, then the more specific ones, and then the conditional or optional ones. If the client sees a difficult open-ended question immediately, they may postpone the booking. A good order for most services is: short topic, preparation option, consent or special condition, then a freeform comment.

You can drag fields around in the admin panel. After reordering them, always reopen the form and check the Details step. Administrators sometimes look only at the field list in settings and do not notice that the reading flow on the public form has become harder to follow.

Conditional Fields and Tying Questions to Services

Two features turn Custom Fields from a simple list of extra lines into a real question builder: conditional display and service binding. They solve different problems. Service binding answers the question "Which service needs this question?" Conditional display answers "Should the next question appear depending on the previous answer?"

Do not combine these mechanics unless you have a clear reason. The more complex the setup, the more scenarios you need to test. If a question is only needed for one service, use service binding. If the question is only needed after a specific answer inside that service, add a condition. That keeps the setup readable both for the current administrator and for the next support specialist who may inherit it later.

Binding Fields to Services

The Bind fields to services setting lets you create questions that appear only when certain services are selected. This is especially useful for sites with multiple service categories: consultations, group sessions, on-site visits, online meetings, diagnostics, or maintenance services. Instead of showing everyone the same long list, you ask each client only what is relevant to their choice.

A good working method is to create one common field that everyone needs first, then add separate fields for service groups. For example, "Briefly describe the goal of your visit" may be universal, while "Enter the service address" should only appear for on-site services. After saving, test at least two paths: one service the field is bound to, and one service it is not. The field should appear in the first path and stay absent in the second.

Conditional Fields

Conditions apply to fields where the user selects a value: checkbox group, radio button group, or dropdown in an if condition. A typical example from the documentation is asking whether the client has a promo code and showing an extra input field only when they choose "Yes." That is better than permanently displaying a "Promo code" field when most clients do not need it.

Conditional fields are especially useful for follow-up questions. For example, the radio button "Is this your first visit?" can reveal a field such as "What would you like to discuss during the initial consultation?" An option like "Do you need help preparing documents?" can show a field with a document list. The main rule is not to build five-level chains. If the client needs to complete a complex questionnaire, it may be better to send a separate form after the booking.

How to Test Conditions

For each condition, test both states: when the field should appear and when it should stay hidden. If the conditional field is required, also test moving to the next step while the field is hidden. The client should never be blocked by a required field they cannot see. The Custom Fields changelog includes fixes related to conditions and hidden required fields, so this test is worth doing even on small forms.

When a Condition Should Be Replaced with Service Binding

If a conditional question depends not on the client's answer but on the selected service itself, use service binding instead. For example, the question "Enter the service address" should not depend on a yes/no answer to "On-site service" if the selected service is already an on-site service. It is cleaner to bind the field directly to that service. That reduces clicks and makes the form easier to understand.

Internal Fields, the Calendar, and Notifications

Not every field should be visible to the client. The Bookly documentation describes internal custom fields that are only visible in the admin panel. The purpose of these fields is to store internal appointment data: the result of a pre-call, an admin note, an internal request category, or staff information that should not appear in the client-facing form.

These fields are hidden using the eye icon. But internal fields should not replace notes, operating procedures, or your CRM. They are useful only when the information belongs to a specific Bookly appointment and needs to sit next to the meeting details. If the data should live in the client's profile, carry over to future visits, or support more advanced segmentation, you are usually better off using a separate client data tool.

Displaying Data in the Calendar

If staff work directly from the calendar, custom field responses should be visible without unnecessary clicks. In Bookly, this is tied to the calendar record template under Settings - Calendar. The documentation mentions the {custom_fields} code for including custom data in the calendar record template, along with individual field codes that can be copied next to each field type.

Do not dump everything into the calendar. The calendar only needs the responses that help a staff member prepare before opening the full appointment record: visit topic, service format, important limitation, or internal preparation status. Long descriptions, detailed questionnaires, and sensitive information are better left in the appointment details, where the administrator can view them intentionally.

Custom Fields in Emails

You can use appointment data in notifications through personal codes. For Custom Fields, the documentation lists the generic {custom_fields} code and individual codes for each field. This is useful, but it requires care. Sending a client a confirmation with a short summary of their answers is one thing. Sending internal notes or sensitive data to staff without checking recipients is something else entirely.

A practical sequence is this: first set up the fields and verify the appointment in the calendar, then add the code to one test notification template, then use the test send tool if your Bookly configuration provides one. Do not add custom fields to every notification at once. Different notification types may have different contexts, recipients, and formatting.

Safe Example Template Without Extra Code

For a staff email, you can use a compact block like this. It is not a PHP snippet and not a plugin edit, just regular logic in a Bookly notification template:

Preparation details:
{custom_fields}

If a field contains sensitive information, do not automatically insert the full block into the client email. First verify exactly which responses are being included. The rollback is simple: remove the code from the notification template and save the changes.

Practical Example: Questions for a Consultation Service

Let us look at a concrete scenario. Imagine the site of a small consulting studio. The client selects the service "Initial Consultation," then chooses a time slot, then fills in contact details. The administrator needs to understand the topic of the request in advance, the preferred meeting format, and whether any documents need to be prepared. At the same time, the form should not feel like a long questionnaire.

Goal

You need to collect three types of information: a short consultation topic, the selected preparation format, and whether the client has a promo code or an internal request number. Some questions should be required, while others should only appear conditionally. The answers should be visible in the appointment record and, if needed, in a staff notification.

Preparation

Before setup, the service, staff member, and page with the Bookly form should already exist. The base booking flow without custom fields should complete successfully. If the form does not yet work without Custom Fields, fix the main scenario first, otherwise it will be difficult to determine which component is actually causing the error.

Setup Steps

1. In Bookly - Custom Fields, create a Text Field named "Consultation topic." Make it required and bind it to the "Initial Consultation" service.
2. Add a Radio Button Group with the question "How should we prepare for the meeting?" and the options "Review the current situation," "Prepare documents," and "Discuss an action plan."
3. Set a default value for the radio group only if it is truly neutral. If any choice changes staff expectations, do not preselect one.
4. Add a Drop Down or Radio Button Group with the question "Do you have a promo code?" and the options "No" and "Yes."
5. Create a Text Field called "Enter promo code" and set it to display only when "Yes" is selected in the previous question.
6. Reorder the fields so the topic comes first, then preparation, then the promo code question.
7. Save the settings, open the form as a visitor, and make two test bookings: one with a promo code and one without.

Expected Result

At the Details step, the client sees only the questions related to the initial consultation. The promo code field expands only when "Yes" is selected. After booking, the administrator opens the appointment and sees the responses in the details. If the calendar template includes the custom fields code, the short answers also appear in the calendar.

Verification and One Important Detail

Do not test only a successful submission. Intentionally leave the required topic empty and confirm that the form asks the user to fill it in. Then select "No" in the promo code question and confirm that the hidden field does not block moving forward. This is an especially important test for conditional required logic: the client should never get stuck because of an invisible question.

How to Verify the Result on the Site and in the Admin Area

After configuration, do not limit yourself to reviewing the Custom Fields section. Custom fields affect several places: the public form, the calendar entry, the appointments list, the edit window, notification templates, and sometimes multi-booking scenarios within one session. That is why verification should follow the full chain: input - save - display - notification - repeat scenario.

Public Form

Open the booking page in a private window. This helps separate the administrator role from the regular client experience. Go through the form up to the Details step and check the following:

• Fields appear only where they are supposed to appear.
• Labels and descriptions are understandable without help from a manager.
• Required fields really do require an answer.
• Conditional fields appear and disappear for the correct option choices.
• The form does not feel overloaded on a mobile-width screen.

If the form has clearly become too long, do not justify it by saying "the administrator needs this information." Ask a better question: which answers can be collected later, and which ones are truly needed before the time slot is confirmed?

Saving the Data in the Appointment

After the test booking, open the Bookly Calendar or Appointments section. In the appointment details, find the custom fields block. The documentation states that responses can be updated: open the edit view, go to the client data inside the appointment, make the change, click Apply, and then save the appointment. Test this workflow on one booking so administrators do not have to figure it out under live conditions.

Checking Multiple Services and Repeated Fields

If the site uses a multi-booking flow, pay attention to the setting for merging repeating custom fields. The documentation describes an option that helps prevent identical fields from being duplicated when the same service is booked multiple times. At the same time, fields may repeat for different services because the questions belong to different service flows. That is logical, but it still needs testing: create several identical bookings and several mixed-service bookings, then compare the Details step.

Result check: if the client books the same service multiple times, identical questions should not repeat for no reason. If they book different services, repetition may be expected because the answers belong to each service separately.

Use Cases for Different Types of Services

The same add-on can provide very different value depending on the type of business. To avoid turning your fields into a generic questionnaire, it helps to think in terms of service scenarios. Below are examples you can adapt instead of copying blindly.

Medical or Wellness Booking

For medical, wellness, and well-being services, custom fields are often useful for staff preparation: first-time or returning visit, general reason for the request, timing constraints, or format preferences. In this category, it is especially important not to collect unnecessary sensitive data in a standard form. If information is truly critical, write the question clearly and verify who can see the response in the admin area and in notifications.

Education and Consulting

Training centers and consultants often benefit from fields for experience level, meeting topic, desired outcome, and preferred format. A good pattern is one short required question plus one optional expanded comment. If you make every question open-ended, staff will have to read long answers before every session, and clients will spend too much time completing the booking.

On-Site Services

For on-site services, tying fields to the right service matters most. Address, building access, parking notes, property type, and a preferred contact window are not relevant to every client. They only matter to someone who selected an on-site format. If you already use the Google Maps Address add-on or another dedicated address tool, do not duplicate it with freeform text unless there is a real reason. Custom Fields is better for additional clarifications, not for replacing a specialized address field.

Internal Team Fields

Internal custom fields can help a team track information clients should not see: "Check documents," "Call one day before the appointment," or "Room setup required." These fields work best when they stay short and standardized. If internal information starts turning into long back-and-forth notes, it is usually better handled in a dedicated notes system, CRM, or internal support process.

SEO, Performance, Security, and Form Usability

Custom fields have almost no direct impact on SEO because they live inside the booking form and do not create standalone indexable content. But they do affect user behavior, which means they can indirectly influence how effective a service page is. If the form becomes too long, unclear, or demanding, visitors may stop before completing the booking.

Performance works the same way. A few extra fields should not, by themselves, become the main reason a page feels slow, but the Bookly form relies on scripts, step transitions, and dynamic states. On the Bookly support forum at WordPress.org, you can find threads about forms that do not respond to Next, JavaScript loading issues, and booking flows that stall before submission. That is not specific to Custom Fields alone, but extra fields make troubleshooting harder if the base form is already conflicting with optimization settings or the theme.

Compatibility with Cache and Optimization

If the form stops progressing after fields are added, temporarily disable aggressive JavaScript optimization for the booking page. Do not blindly wipe out every site setting. First test the page in a private window, then clear the cache, then exclude the booking page or Bookly scripts from minification, combination, or delayed loading if your cache plugin allows it. After each change, repeat the exact same test scenario.

Minimal CSS Tweak for Better Readability

Sometimes the field works correctly, but the description or option group looks too cramped inside the site theme. If you have a safe place for custom CSS, such as Appearance - Customize - Additional CSS or a CSS field provided by your theme, you can add a small spacing tweak. This is not a WordPress core edit and not a change to plugin files.

/* Improve the readability of Bookly custom questions on the Details step */
.bookly-form .bookly-custom-field-row,
.bookly-form .bookly-custom-fields-container {
  margin-bottom: 14px;
}

.bookly-form .bookly-custom-field-row label {
  line-height: 1.35;
}

Before applying it, inspect the CSS classes in your browser on the actual site: the theme or form version may differ. If the selector does not work, do not force it with random !important rules. Instead, find the real container class on your page. Rolling back is simple: remove the CSS block and clear the cache.

Security and Personal Data

Do not use custom fields as a place to collect sensitive documents, passwords, payment details, or information that should not be stored in a regular WordPress record without a dedicated handling policy. If you need file uploads, review the Files add-on and its file storage rules. If you need payment data, use payment integrations instead of a text field. Custom Fields is meant to collect booking-related clarifications, not to replace secure forms, payment systems, or the site's legal and privacy setup.

How to Design a Question Set Without Overloading the Form

The most common mistake with custom fields is treating them like an unlimited questionnaire. Technically, you can create many fields, but the client sees them at the moment they have already chosen a service and a time slot. At that stage, their goal is to finish the booking, not complete a long interview. That is why a good setup starts not with "What else can we ask?" but with "Which answer would actually change how we prepare for the service?"

A useful way to design the field set is to follow this chain: input data - Bookly logic - admin outcome - verification - error symptom - fix. This approach helps prevent adding fields just because you can. If an answer does not affect preparation, the calendar, a notification, an internal process, or service quality, it probably should not be asked before the booking is submitted.

Split Questions Into Three Levels

The first level is required questions without which the booking cannot be accepted. There should be only a few of them. The second level is useful questions that improve preparation quality but should not block the booking. These are usually better as optional fields. The third level is internal or follow-up information that an administrator can fill in after contacting the client. For that third level, internal custom fields are often a better fit than public fields on the Details step.

For example, in a consultation flow, the meeting topic may be the only required field. The preparation level, document link, preferred contact channel, and comment are better left optional or conditional. For an on-site service, the address may be required if it is not collected by another add-on, while details such as gate access or parking can remain optional. For a group session, the participant's age may be required, while prior experience can be an optional choice.

Map the Data First, Then Build the Fields

Before creating fields, make a short map. It should include not just the question text, but also where the answer will be needed:

• In the public form - the client should understand the question within a few seconds.
• In the appointment details - the administrator should be able to find the answer quickly.
• In the calendar - the staff member only needs the shortest possible preparation signal.
• In the notification - the recipient should only see the data they actually need.
• In a repeat booking - the answer should still need to be collected again, otherwise it belongs in the client profile, not the appointment field set.

This map is especially helpful when several staff members each want their own questions added. One person asks for "How did you hear about us?", another wants "What are your expectations?", and a third asks for "Best time for a callback." All of those may be useful, but not all of them should be required, and not all of them belong on the booking form. Some can go into a post-booking email, some into an internal note, and some into the client profile or CRM.

How to Shorten a Long Form

If the Details step looks too long after setup, do not remove fields at random. First find repeated questions. Then see whether several text fields can be replaced with one choice-based field. After that, check which questions only belong to part of your services and bind them accordingly. Finally, decide which questions can be revealed only conditionally.

Sometimes it is better not to ask the question immediately, but to include it in a staff notification as a preparation checklist item: "If the consultation topic is unclear, contact the client." That reduces the burden on the client while preserving process control. Custom Fields should support the booking, not turn it into an obstacle.

Working rule: if a field is not used in the calendar, the appointment details, staff preparation, or service verification, remove it from the form or make it internal. A question that leads to no action only reduces booking completion.

Multilingual Sites, WPML, and Field Wording

The CodeCanyon page lists WPML compatibility, and the WordPress.org description of Bookly mentions translating the interface and notifications through WPML. That matters even more for Custom Fields, because the client sees the field label, description, answer options, and text blocks directly. If the site runs in multiple languages, do not leave custom questions in only one language, even if the rest of the form has already been translated.

The Custom Fields changelog has also included a fix related to translating certain custom fields through WPML. That is a good reminder not to assume the translation will "just carry over" everywhere. After configuring a multilingual form, run a test booking in every site language and verify three places: the public Details step, the appointment details in the admin area, and the notification output.

What to Translate First

All client-facing elements need translation: the field name, description, options in a checkbox group, radio button group, and dropdown, the Text Content informational text, and the phrases in notifications where the answers appear. Technical codes such as {custom_fields} and the individual field codes must not be translated because they need to remain functional template tokens.

If a field is internal and only visible to your team, the translation choice depends on how your team works. For a Russian-speaking admin team, internal fields can remain in Russian even on the English version of the site. But if staff work in multiple languages, it is better to choose one internal language or use short standardized answer options.

Testing the Multilingual Flow

Do not test only the text shown in the form. Test the saved values too. Make one test booking in Russian, then another in English or another site language. Open both records in the admin panel and see whether staff can easily tell which language the response came in and whether it needs manual translation. If a choice-based field is inserted into a notification, check which language version of the answer the recipient actually receives.

For multilingual sites, it is usually better to avoid freeform text when predefined options are enough. Freeform answers are harder to analyze and harder to translate. A dropdown or radio button with translated options generally produces cleaner results.

Wording That Reduces Errors

Field text should be short and specific. In the description, explain what the client should do if they do not know the answer. For example: "If this is your first booking, briefly explain what you would like to discuss. If you are not sure, enter "consultation needed"." That works better than an empty field labeled "Comment," because the client understands the expected answer format.

For required fields, avoid questions that require long reflection. If the answer helps the administrator but the client may not know it right away, the field should be optional. Otherwise, the form will block bookings from the very people who need help most.

Video on Adding Fields in Bookly

The developer provides a video related to the Custom Fields add-on, linked from the official add-ons list. It is most useful after reading the configuration section: the video covers the intent of "how to add custom fields in Bookly" and helps connect the written instructions to the actual interface.

Before following the steps from the video, check the current documentation: the Bookly interface is updated from time to time, and the exact menu items and screen layouts may differ from older recordings.

When CodeCanyon Bookly Custom Fields Is the Right Choice

This add-on is worth using if Bookly PRO is already running on the site and the business needs structured extra questions on the details step. It works especially well in scenarios where questions depend on the selected service, the answers need to be stored in the appointment details, and the administrator wants to see them in the calendar, appointment card, or notifications.

Before rolling it out, do not try to build the "perfect questionnaire for every case." Start with three to five fields that are genuinely needed, test the form, see how administrators actually use the responses, and only then add more conditions or service binding. The best Bookly Custom Fields setup is not the one with the most questions, but the one with the smallest set of data that helps deliver the service without creating unnecessary friction for the client.

If your review shows that the add-on fits your workflow, you can move to the download section and get the WordPress version to test on your site. Run the first round of testing on a backup or staging environment, and only move fields into the live form after they have passed the full route: displayed in the form, saved in the appointment, shown in the calendar, and delivered correctly in notifications.