Inherited a Cvent account? Audit this first

The handover usually arrives as a login and a sentence. “Everything is in there.” The admin has moved on, or the client has switched agencies, or an internal team has been told the next event is theirs now. The account works, in the sense that events have run out of it. Nobody can tell you why it is set up the way it is.

That is the risky moment. You do not know which templates are current, which integration is quietly failing, or which email still carries last year’s logo. Build the next event on top of that and you inherit every problem along with the account.

So before anyone builds anything, run an audit. Below is the audit we would run before building on any account we did not set up, in the order we would do it. For each area: what to look for, and what happens if you skip it.

1. Account access and user roles

Look for: every user who can log in, what each one can do, and who the account owner is on Cvent’s side. Check for shared logins, people who have left the organisation, and former agency staff who still have admin rights.

Risk if ignored: someone outside the team can still edit live events or export attendee data. Shared logins also mean you cannot tell who changed what, which matters the first time a registration page breaks the week before launch.

Remove anyone who should not be there. Give each person their own login with the narrowest role that lets them do their job, and write down who the main admin is.

2. Event templates and naming

Look for: which events or templates new events are actually copied from, and whether the names tell you anything. “Conference 2025 FINAL v3 copy” is a clue. So are three templates that look identical but differ in one setting.

Risk if ignored: the next event gets copied from the wrong source and carries old dates, old pricing or retired branding into a new build. When naming has no logic, nobody can find last year’s event to compare against.

Pick one template per event type, retire the rest, and agree a naming convention before the next event is created.

3. Registration paths, types and questions

Look for: every registration type and path in the events you are about to reuse (attendee, speaker, sponsor, VIP, guest) and the logic behind each. Look at the questions too: which are required, which feed a report or an integration, and which nobody can explain.

Risk if ignored: conditional logic is where inherited builds break. A path that shows the wrong pricing to the wrong person, or a required question that blocks mobile users, will not show up until real people start registering.

Register a test person through every path, on desktop and on a phone, before you change anything. Then you know what “working” looked like.

4. Email templates

Look for: confirmation, modification, cancellation, reminder and invitation emails. Check sender name and reply-to address, logos, footer details, links, and whether each one still says what the current event needs it to say.

Risk if ignored: emails are the part of the account people forget exists. A confirmation from a former employee’s address, or a reminder pointing to a dead page, goes to every registrant before anyone on the team sees it.

Send yourself every email in the sequence. Read them as an attendee would.

5. Payment and merchant settings

Look for: which merchant account each paid event uses, who holds the relationship with the payment provider, the currency and tax settings, refund rules, and any discount codes still active.

Risk if ignored: this is the most expensive area to get wrong. Money can land in an account the client no longer controls, an old discount code can keep circulating, and a refund policy in the settings can contradict the one on the website.

Confirm the merchant account with whoever owns the client’s finances, not just the person who handed over the login. Deactivate any code you cannot account for.

6. Integrations and sync that fail silently

Look for: every connection to a CRM, marketing automation platform, webhook or third-party tool. For each one, check when it last synced, whose credentials it runs on, which fields it maps, and what happens when it errors.

Risk if ignored: integrations do not announce that they have stopped. A sync authenticated with a departed admin’s credentials can break when that user is deactivated, and nobody notices until the sales team asks where the event leads went.

List each integration, its owner and what it is supposed to move. Run a test registration and watch it land on the other side. If Salesforce is involved, our Cvent and Salesforce integration guide covers the mapping and matching decisions worth checking.

7. Data fields and consent

Look for: custom contact fields, how consent and opt-in are captured, where they map, and how long attendee data is kept. Look for duplicate fields that hold the same information under different names.

Risk if ignored: consent that does not map correctly means contacts get emailed who never agreed to it. Duplicate fields split the same answer across two places, so every report built on them is wrong in a way that is hard to spot.

Agree one field for each piece of information, confirm the consent wording with whoever owns compliance on the client side, and note what each field feeds.

8. Website and branding templates

Look for: the event website and registration page templates, theme settings, fonts, colours, images and any custom code. Compare what is live against the client’s current brand guidelines.

Risk if ignored: branding is where inherited accounts drift furthest. Each previous editor made a small change in a hurry, and the result is a registration page that looks like a cousin of the brand. That page is the first thing an attendee sees, and it is the hardest thing to fix in the week before launch.

9. Reporting

Look for: saved reports, scheduled reports and who receives them, dashboards, and the numbers the client actually uses to judge an event.

Risk if ignored: scheduled reports keep going to people who have left. Reports built on retired fields return blanks. When leadership asks how the last event compared, nobody can rebuild the numbers.

Run the reports the client relies on and check they still return sensible data. Delete or reassign the ones nobody reads.

10. Documentation and ownership gaps

Look for: anything written down. Build notes, naming rules, integration settings, which vendor owns what, and who to call when something breaks.

Risk if ignored: without documentation, every decision the previous admin made has to be reverse engineered under deadline pressure. The next handover then starts from the same place this one did.

If nothing exists, the audit itself becomes the first version of the documentation. Write down what you found as you go.

Turn the findings into a fix list

An audit gives you a list. Sort it in three columns: what could leak data or money (access, payments, consent), what could break the next event (registration, emails, integrations), and what is untidy but harmless for now (naming, old reports). Fix the first column this week and the second before the next event opens.

If you want a quick read on where things stand first, the free Cvent Program Health Scorecard scores registration, integrations, reporting and documentation in a few minutes.

Get it fixed and handed over properly

The point of the audit is not to know what is wrong. It is to end up with an account the next person can pick up without a guided tour. That means clean templates, integrations someone owns, and notes written around the build that actually exists.

Our builds include templates, handover notes and walkthroughs and documented integrations, so the next person does not start from a login and a sentence. Fixed scope, agreed before we start.

Need this built properly for a client? Eventengin designs and builds event websites and registration, white-label, for agencies. Talk to us.