Knowledge Base Archive

Setting Up a Multi-Language Cvent Event: Website vs. Attendee Hub (They’re Not the Same System)

This is a real point of confusion that comes up even for planners who’ve run multilingual events before, and it was directly confirmed by Cvent’s own support team in a recent community thread: your event website (the registration site) and your Attendee Hub (web and mobile) are two independent systems when it comes to language. Turning on a second language for one does nothing for the other. If you only set up one, attendees can end up registering in fluent French and then landing in an Attendee Hub that’s still entirely in English.

Here’s how to set up both correctly, and what still needs manual translation either way.

Part 1: Your Event Website (Registration Site)

Step 1: Turn on the multi-language event setting

Go to General → Event Information and enable the multi-language event setting for your event. This is the master switch — without it, none of the language tools below are available.

Step 2: Add the Language Selector Widget to your site

In Site Designer, add the Language Selector Widget to your event website. This is what lets registrants actually switch languages themselves, and it applies across your website, the registration process, and any surveys tied to the event — not just the homepage.

Step 3: Set up a separate invitation list per language

With a multi-language event, you’ll maintain a separate invitation list for each language you’re supporting. This matters beyond the website itself — the confirmation and reminder emails tied to each list are automatically translated to match, so a registrant on your French invitation list gets French emails without any extra setup on your end.

Step 4: Know what's NOT automatically translated

Cvent auto-translates standard system labels and instructional text. It does not auto-translate:

Session names and descriptions
Custom questions and their answer options
Any custom text blocks, banners, or instructions you wrote yourself

This content has to be translated manually — which is what Language Management is for.

Step 5: Manually translate custom content in Language Management

Go to Website & Registration → Website → Language Management. This screen lists every piece of system text in your event by Text ID, alongside its Default Text, with a place to enter Custom Text for each language you’ve added.

Use Advanced Search to filter by Registration Path, Text ID, Default Text, Custom Text, or Area/Type — the full list can be long, and searching by a word you know is on the page (like “Agenda” or “Submit”) is faster than scrolling.
Click the pencil icon next to a Text ID to enter your translation, then the floppy disk icon to save it.
Repeat for each custom question, session title, and description you’ve written — these won’t appear translated on your live site until you’ve entered them here, even if the rest of the page looks fully translated.

Part 2: Your Attendee Hub (Separate From the Website)

This is the part that catches people off guard: enabling multiple languages on your event website does nothing for your Attendee Hub. They’re managed independently, on both web and the mobile app.

Step 1: Enable additional languages for Attendee Hub

Attendee Hub has its own language settings, separate from the event website’s multi-language toggle. Once a second language (say, French) is enabled for the Hub, most of its system text — navigation, buttons, standard labels — is automatically translated by Cvent, the same way the website’s system text is.

Step 2: Manually translate planner-created content

Just like the website, anything you wrote isn’t auto-translated:

Session names and descriptions
Custom pages or sections
Any other custom text you’ve added to the Hub

Translate these under Marketing → Language Management, selecting the specific language (e.g., French) and working through the Translations tab.

A note on the "In Progress" status

If you check Language Management and see a language marked “In Progress,” that’s not an error or a sign that something’s broken — it just means some strings for that language have been customized already. It doesn’t block Cvent’s automatic system-text translation from working in the meantime; it’s purely a marker for how much of your own manual translation work is done.

Step 3: Know how attendees actually change their language

This differs by platform, and it’s worth knowing so you can tell attendees what to expect:

Attendee Hub (web): may default to the attendee’s browser language automatically. Attendees can change it anytime under Profile → Language.
Attendee Hub (mobile app): initially follows the device’s language setting at the time the app is installed — it won’t update automatically if they change their phone’s language later. Attendees can change it manually under Profile → Settings → Language & Time.

Common issues and how to fix them

Attendees registered in a second language, but the Attendee Hub is still in English. This is the core gotcha — the Attendee Hub has its own separate language setup. Confirm you’ve enabled the second language for the Hub specifically, not just the event website.

Some Attendee Hub text is translated, other parts aren’t. System text is automatic; anything you wrote (sessions, custom pages, custom text) needs to be entered manually under Marketing → Language Management.

A language shows “In Progress” and you’re not sure if it’s working. It is — this status only reflects how much manual translation you’ve completed, not whether the automatic system translation is functioning.

A registrant’s app didn’t switch language when they changed their phone’s language. Expected behavior — the app locks to whatever language the device was set to at install. They’ll need to change it manually in the app under Profile → Settings → Language & Time.

The takeaway

Treat your Cvent event website and your Attendee Hub as two separate translation projects, even though they’re part of the same event. Each has its own enablement step, its own automatic system-text translation, and its own Language Management screen for the custom content you wrote yourself. Set both up deliberately, and check Language Management on each platform specifically — not just one — before you assume your event is fully translated.

Setting Up a Multi-Language Cvent Event: Website vs. Attendee Hub (They’re Not the Same System) Read More »

Why Your Cvent Discount Code Is Over-Applying (And How to Fix It)

By Nitish Verma

A discount code that “over-applies” usually shows up one of two ways: either it’s discounting registrants who shouldn’t qualify at all, or it’s stacking with another discount to produce a lower price than either one was supposed to give on its own. Both are almost always a scoping problem, not a bug — Cvent’s discount codes are permissive by default, meaning a code applies broadly unless you specifically narrow it. This guide walks through where that narrowing happens and the most common places people miss a restriction.

Understand the default behavior first

When you create a discount code without touching its restriction settings, it will, by default:

Apply to any registration type or attendee category, not just the one you had in mind
Remain valid for the entire registration period, not just a promotional window
Be usable alongside other active codes, unless you’ve explicitly set it to be exclusive

None of that is a malfunction — it’s the code doing exactly what an unrestricted code is built to do. The fix in every case below is the same idea: go back into the code’s settings and add the restriction that was missing.

Cause 1: The code isn't scoped to a specific registration type

If you created a discount meant only for, say, returning exhibitors, but didn’t restrict it to that category, it will discount new exhibitors too the moment they enter the code — whether or not they were supposed to have access to it in the first place.

The fix: Open the discount code and find the “Availability by Attendee Category” (or similarly named) field. Instead of leaving it set to all categories, select only the specific registration type(s) it should apply to.

Cause 2: No date window on the code itself

It’s common to assume a discount will “naturally” stop working once general registration closes — but if the code has no start or end date of its own, it stays valid for as long as the registration form is live, even past whatever informal deadline you communicated for the promotion.

The fix: Set an explicit start date and end date on the code, separate from the event’s overall registration deadline. If the promotion is meant to run only during an early-bird window, the code’s dates should match that window exactly, not the full registration period.

Cause 3: Volume logic was rebuilt with a second code instead of using the built-in condition

A common workaround — and a common source of stacking issues — is creating a second discount code to simulate “if 2+ people from the same group register, apply an extra discount,” rather than using Cvent’s built-in minimum-registrants condition on a single code. Two codes layered this way can combine unpredictably, especially if neither one was set to exclusive.

The fix: Delete the second/workaround code and rebuild the logic using the “minimum attendees already registered” (or equivalent) condition on the original code. This keeps the volume logic self-contained in one place instead of relying on two codes interacting correctly.

Cause 4: Multiple codes are allowed to combine

If a registrant can enter more than one valid code on the same registration and both apply, you’ll see a final price lower than either discount alone — which often looks like a bug but is actually the combinability setting doing what it was left to do.

The fix: If codes are not meant to stack, set the code (or the event’s overall discount settings, depending on your platform version) to restrict combining with other discounts. If some combinations are intentional and others aren’t, you’ll need to review each active code individually rather than relying on a single blanket setting.

Cause 5: The discount is applied to the full registration total instead of one fee item

If your event has multiple fee items (say, a base registration fee and an add-on), a percentage-based discount applied at the wrong level can end up reducing the total rather than just the specific fee it was meant to affect — which can look like it’s “discounting more than it should” even though only one restriction is technically wrong.

The fix: Check whether the discount code is scoped to a specific fee item or applied at the overall order level. If you have separate fee items set up (see the guide on registration types and pricing tiers), scope the discount to only the relevant one.

Testing checklist before you go live

Register a test account that shouldn’t qualify for the code — confirm it’s rejected or simply doesn’t reduce the price.
Register a test account that should qualify — confirm the discount amount matches exactly what you intended, not more.
If you have more than one active code, try entering two at once on a test registration to confirm they behave as expected (either both apply intentionally, or the second is blocked).
Try registering after the code’s end date to confirm it’s correctly expired.

The takeaway

A Cvent discount code that’s discounting more than intended is almost always missing one of four restrictions: a category limit, a date window, an exclusivity setting, or the right fee-item scope. Rather than troubleshooting the symptom on a live registration, open the code’s settings directly and check each of these one at a time — and always test with an account that shouldn’t qualify, not just one that should, before you open registration to real attendees.

Why Your Cvent Discount Code Is Over-Applying (And How to Fix It) Read More »

Why Some Mandatory Question Answers Are Missing From Your Cvent Report (And How to Prevent It)

By Nitish Verma

This is a real problem people run into often enough that it shows up regularly in the Cvent Community forum: a question is set to required, registrants clearly had to answer it to complete registration, and yet when the report is exported, some rows have an answer and others are blank. It looks like a bug. Most of the time, it isn’t — it’s one of a handful of setup or report-building issues that are easy to miss.

Here’s what’s actually going on, and how to check each cause.

Cause 1: The question was added after some people already registered

“Mandatory” only applies going forward from the moment a question is added and published to the registration form. If you added or edited a question after registration had already been open for a while, everyone who registered before that change simply never saw it — so there’s nothing for them to have answered. Their blank answer isn’t a report error; it reflects the registration form they actually filled out.

How to check: Compare the registration timestamps of the blank rows against the date you added or last edited the question. If the blanks cluster before that date, this is your cause.

Cause 2: The question is required only for certain registration types or categories

A question can be marked mandatory overall but only actually required for specific attendee categories — this shows as a “partial” requirement in the question settings rather than a flat “required for everyone.” If a registrant’s category wasn’t included in that requirement, they were never forced to answer it, even though the question looked mandatory when you were viewing it as an admin.

How to check: Open the question’s settings and check whether the “Required” status is set per category rather than globally. Cross-reference the blank rows against which registration type or category those registrants belong to.

Cause 3: The question has conditional (branching) logic

If the question only displays based on an earlier answer — for example, “What size booth do you need?” only shown to people who answered “Exhibitor” to a prior question — then anyone who didn’t trigger that condition never saw the question at all. It wasn’t skipped; it was never shown, and that’s expected behavior, not a data loss issue.

How to check: Look at the question’s display logic settings and trace which earlier answer(s) trigger it. Then check whether the blank rows share a common answer to that earlier question that doesn’t trigger the branch.

Cause 4: The report doesn't include that question as a column

This is the most common cause, and it’s a report-building issue rather than a registration issue. If you’re using a standard or previously-saved report template, it may not automatically pull in a question added later, or it may be scoped to a specific set of fields that don’t include this one. The registrant did answer it — the data exists — the report just isn’t showing that field.

How to check: Build a fresh custom report (rather than reusing an old saved one) and explicitly add the question as a field/column. If the answers appear now, this was the cause.

Cause 5: The question was deleted or deactivated after the deadline passed

If a question was deleted (not just deactivated) after registration closed, its answers may no longer appear in the standard question summary report, even though people did answer it while it was live. This is a known point of confusion — deleting a question to “clean up” a form after a deadline can quietly remove it from reporting as well.

How to check: Look in your Inactive Questions or Question Library (rather than the active question list) — if the question still exists there but was deactivated rather than deleted, its historical answers are usually still reportable. If it was fully deleted, you may need to pull an older saved report generated before the deletion, or check with support about whether the raw response data is still retrievable.

Cause 6: The registrant was added manually, not through the registration form

Registrants added directly by an admin (walk-ins, manual entries, imports) don’t always go through the same form flow as someone self-registering online — which means they can be added without ever being prompted for that question, mandatory or not.

How to check: Cross-reference the blank rows against your registration source/method field, if your report includes one. Manual or imported registrations are the likely source.

Prevention checklist for future events

Finalize your required questions before opening registration — adding mandatory questions mid-registration-period is the single biggest cause of this issue.
When a question only needs to apply to certain attendee types, use category-specific requirements deliberately, and document which categories they apply to somewhere your team can reference later.
Build reports fresh (or update saved templates) whenever you add a new question, rather than assuming older templates will pick it up automatically.
Deactivate questions instead of deleting them once a deadline passes, if you may need to report on the answers later.
If you’re adding registrants manually, use a process that walks through the same required fields as the public form, rather than a bare-bones admin entry.

The takeaway

A blank answer for a “mandatory” question in a Cvent report is almost always explainable once you check the timing of the question, whether it was required for that specific registrant’s category, whether conditional logic kept it hidden, and — most often — whether the report itself was actually pulling that field in the first place. Work through these in order and the pattern in your blank rows will usually point straight to the cause.

Why Some Mandatory Question Answers Are Missing From Your Cvent Report (And How to Prevent It) Read More »

How to Set Up and Manage an Event Waitlist in Cvent (Without Overselling Capacity)

By Nitish Verma

A waitlist sounds like a simple feature until you actually need it to do two things at once: stop people from registering past capacity, and automatically re-fill a spot the moment someone cancels. Get the setup wrong and you end up with one of two problems — an event that’s technically “full” but still lets people in, or a waitlist that just sits there collecting names nobody ever gets invited from.

This guide covers how to set capacity correctly at every level it applies to, how to choose between automatic and manual waitlist processing, and what to check when a waitlist isn’t converting the way it should.

Decide where capacity actually needs to be capped

Before touching any settings, be clear on what is capped — this is the step people skip, and it’s the reason a waitlist can “work” at the event level while a specific session or attendee category still oversells.

Event-level capacity — a hard cap on total registrations for the whole event.
Category-level capacity — a cap on one specific registration type (e.g., only 6 exhibitor booths, even though the overall event has no cap).
Session-level capacity — a cap on an individual breakout or workshop, independent of the overall event cap.

If you only set a cap at the event level, a single popular session or category can fill up while the event overall still shows availability — and attendees will be confused when they’re told a session is full but the event isn’t.

Step 1: Set the capacity limit(s)

Go to your event’s Registration Settings (or Event Info, depending on your Cvent platform version) and find the Capacity or Registrant Rules section.
Enter the maximum number of registrants for the level you’re capping — event, category, and/or session.
Leave capacity fields blank for any level that shouldn’t be limited. A blank field is treated as unlimited, not zero — an easy mistake if you’re used to other platforms where blank means “closed.”

Step 2: Turn on waitlisting and write the messaging attendees will see

Enable the Waitlist toggle for the event (and separately for any session or category that needs its own waitlist).
Set the sold-out message — the text shown when someone hits a full event, category, or session. Be specific here; a generic “this event is full” message doesn’t tell people a waitlist option exists.
Set the waitlist link/button text — what registrants click to join. “Join the Waitlist” performs better than vague phrasing like “Learn More,” since it sets a clear expectation.

Step 3: Choose automatic or manual waitlist processing

This is the setting that determines whether your waitlist actually does the work for you.

Automatic processing — the moment a spot opens (someone cancels or is removed), the system automatically registers the next person on the waitlist, in the order they joined, and sends them a confirmation. Best for high-volume events where you don’t have time to manage this manually.
Manual processing — an admin has to review the waitlist and invite the next person, who then has to confirm before the spot is locked in. Best when you need to control exactly who fills a spot (e.g., prioritizing by attendee category, sponsor tier, or approval status) rather than strictly by wait time.

If you choose manual, make sure someone on your team actually owns checking the waitlist regularly — a manual waitlist with no one monitoring it is functionally the same as having no waitlist at all.

Step 4: Set up the emails that go with it

A waitlist is only as good as the communication around it. At minimum, confirm these are turned on and correctly worded:

Waitlist confirmation email — sent when someone joins the waitlist, so they know they’re on it (not registered).
Spot-available / invitation email — sent when a spot opens, whether that’s an automatic confirmation or a manual “you’re invited to register” prompt.
Cancellation confirmation email — sent to the person who cancels, which is what triggers the waitlist to check for the next name.

If you’re using manual processing, the invitation email should include a clear deadline to respond, and your process should define what happens if that deadline passes (move to the next person automatically, or hold the spot open).

Step 5: Test the full cycle before you rely on its that go with it

Don’t just test that the waitlist accepts someone — test that it actually fills a spot.

Set a temporary low capacity (e.g., 2) on a test category or session.
Register two test accounts to fill it, then register a third — confirm they’re offered the waitlist, not blocked outright.
Cancel one of the first two registrations.
Confirm the third account is automatically registered (if automatic) or receives an invitation (if manual), and that the correct emails fire at each step.
Reset the capacity back to its real number once testing is confirmed working.

Common issues and how to fix them

People are still registering after the event shows “full.” Check whether capacity is set at the level you think it is. A cap on the event overall won’t stop registrations to an uncapped category or session within it.

The waitlist isn’t moving anyone up after a cancellation. Confirm the cancellation is going through the system’s cancel workflow, not just a manual deletion of the record — a deleted registration doesn’t always trigger the same waitlist check that a proper cancellation does.

Waitlisted people never hear anything. Check that the waitlist-related email triggers are actually turned on — they’re separate from your standard registration confirmation emails and are easy to leave off during initial setup.

A category or session is oversold despite a waitlist being “on.” Waitlisting has to be enabled at the same level as the capacity that’s being hit — enabling it only at the event level won’t protect a specific session or category.

The takeaway

A working Cvent waitlist comes down to matching three things at the same level — capacity, waitlist enablement, and the emails that drive it — rather than assuming an event-level setting covers everything underneath it. Set the cap where the real constraint is (event, category, or session), pick automatic or manual based on how much control you need over who fills a spot, and run a full cancel-to-refill test before you trust it on a live event.

How to Set Up and Manage an Event Waitlist in Cvent (Without Overselling Capacity) Read More »

How to Set Up Multiple Registration Types with Different Pricing Tiers in Cvent

By Nitish Verma

If you’re running an event where different groups of people need to pay different fees — say, a trade show where new exhibitors pay $750 for a booth and returning exhibitors pay a lower renewal rate — Cvent can absolutely handle it. But because the setup touches three different areas of the platform (registration types, pricing, and registration paths), it’s easy to configure just one piece and end up with pricing that doesn’t apply correctly, or a registration type that attendees can’t even select.

This guide walks through the full setup, in order, and covers the mistakes that most commonly break it.

Before you start: know the difference between three settings

People often use “registration type,” “category,” and “path” interchangeably — but in Cvent they control different things, and mixing them up is the #1 reason pricing tiers don’t work as expected.

Registration Type / Attendee Category — defines who someone is (e.g., New Exhibitor, Returning Exhibitor, Member, Non-Member). This is the label attached to their record.
Fees & Pricing — defines how much each registration type pays, and can include early-bird windows, deadlines, or tiered pricing.
Registration Path — defines what registration flow a person is routed through based on how they access the site (a link, an invitation, or a public registration page). Paths are what let you show different fees, questions, or steps to different audiences.

If any one of these three isn’t configured, the other two won’t behave the way you expect — the most common symptom is a fee that either doesn’t apply, applies to everyone, or a registration type attendees can’t select at all.

Step 1: Create your registration types

Open your event and go to Registration → Registration Types (or General → Registration Types, depending on your Cvent platform version).
Click Add Registration Type for each audience you need — for a trade show example, you’d create:
- New Exhibitor
- Returning Exhibitor
Give each one a clear, attendee-facing name. Avoid internal shorthand (“Ret. Exh.” confuses registrants) — this label often appears on the registration form itself.
Set the status of each type to Active only once you’re ready for people to register under it. Leaving unused types active is a common source of registration confusion later.

Step 2: Set up the fees for each type

Go to Fees & Payment (sometimes labeled Pricing depending on your product).
Create a separate fee item for each registration type — don’t try to reuse one fee item and discount it down for the second group. Separate fee items give you cleaner reporting and avoid the discount-code conflicts covered below.
For each fee, set:
- Amount (e.g., $750 for New Exhibitor, $500 for Returning Exhibitor)
- Availability window, if the fee should only be offered during a certain registration period
- Attendee category / registration type it applies to — this link is what actually ties the price to the right group. It’s the step most often skipped.
If you’re also capping how many booths or seats are available per category, set the capacity for that fee item here too, not just at the overall event level. Capacity set only at the event level won’t stop one group from using up all the spots meant for another.

Step 3: Build (or check) your registration paths

If exhibitors are registering through a single public link, you’ll typically need a path with a selection step — a screen where the registrant picks “New Exhibitor” or “Returning Exhibitor” before seeing pricing.
If you already know who’s who (e.g., you have a list of last year’s exhibitors), you can instead use an invitation list tied to a specific registration type, so returning exhibitors land directly on their pricing without having to self-select. This also reduces the risk of someone picking the cheaper option they don’t actually qualify for.
Test each path in preview mode as a registrant would see it — not just from the admin view — before sending invitations. Admin previews sometimes show all types regardless of path restrictions, which can mask a setup error.
Registration paths control who sees which registration type in the first place.

Step 4: Apply discount codes carefully (if you're using them on top of tiered pricing)

This is where a lot of setups break. If you’re layering a discount code on top of an already-tiered fee structure (for example, “2+ booths get 10% off,” in addition to the New/Returning pricing), go to Discount Codes and scope the code narrowly:

Restrict it to the specific registration type(s) it should apply to — don’t leave it available to all categories by default.
If the discount should only kick in once a minimum number of registrants are already in a group, use the “minimum attendees already registered” condition rather than trying to recreate that logic with a second discount code layered on the first.
Set a clear start and end date on the code itself, separate from your general registration deadline, if it’s meant to apply only during a promotional window.

Discount codes that aren’t scoped tightly enough are the most common cause of a fee being “over-applied” — where a discount meant for one small group ends up reducing the price for everyone who registers.

Step 5: Test with real accounts, not just the admin preview

Before you launch:

Register a test account under each registration type.
Confirm the correct fee appears, not a default or blended price.
Confirm any discount code behaves as scoped (apply it to a test account that shouldn’t qualify and make sure it’s rejected).
Pull a quick registration report and check that the registration type field is populating correctly for each test record — this is what you’ll rely on later for reporting and badge printing.

Common issues and how to fix them

A registrant sees the wrong price. Check whether the fee item is actually linked to their registration type (Step 2) — this link is separate from simply naming the fee similarly.

A discount code is discounting more than it should. Re-check the code’s category and date restrictions. A code with no restrictions applies to every registration type and every date by default.

An attendee can’t find their registration type on the form. This is almost always a registration path issue — either the type wasn’t added to the path they’re using, or the path is routing them somewhere else entirely.

Reports show the wrong category for a group of registrants. If people registered through a shared link rather than an invitation list, confirm the selection step in the path was actually presented — some path configurations default silently to one category if the selector isn’t required.

The takeaway

Multiple pricing tiers in Cvent aren’t complicated once you treat registration types, fees, and paths as three separate, connected settings rather than one combined step. Set them up in that order, scope any discount codes tightly, and always test as a registrant before you open registration — it’ll save you from having to manually correct pricing on live registrations later.

How to Set Up Multiple Registration Types with Different Pricing Tiers in Cvent Read More »