Project teams move fast in SurveyTester once the company account is prepared for them. Almost everything a project manager picks in the Create Project dialog, from the project template to the result filters, and almost everything the automatic checks report, from spelling to personal data, comes from settings an administrator made once. This checklist walks through those settings in the order in which they depend on each other. Done once and reviewed per quarter, it keeps every project consistent.
Tip
This checklist is also available as a handout: SurveyTester Admin Setup Checklist (Word) · PDF. Once the company is set up, hand the project teams the companion article Best practices: from a new project to sign-off.
All settings live behind the gear icon in the top bar, Administration & Settings. The menu follows the headings below.
The checklist at a glance
| # | Setting | Why it comes first | Admin menu |
|---|---|---|---|
| 1 | Roles, then users | A user without a role sees nothing | Roles, Users |
| 2 | Folder structure | Folders carry access and templates | Folder Structure |
| 3 | Project types with classification fields | Every issue is classified with them | Project Types |
| 4 | Auto-Detect and personal-data settings | Define what the automatic checks report | Project Types, Company Settings |
| 5 | Company dictionary | Stops false spelling findings on brand names | Company Dictionary |
| 6 | AI engines and features | AI is off until you turn it on | AI Engines, AI Usage |
| 7 | Templates: result filters, test plan, mail, forms | Offered to every new project | Test plan templates, Mail Templates, Forms |
| 8 | Extension rollout and notification defaults | Testers need the extension on day one | outside the admin area |
1. Roles first, then users
Access in SurveyTester is role-driven: a person belongs to your company through the roles they hold, and a role is a set of permissions. There are more than a hundred permissions, from Add projects and Test survey through Use SurveyBot and Edit test cases to Sign off project and Manage company dictionary.
A fresh company comes with three roles that cover most teams:
| Role | Typical holder | What it can do |
|---|---|---|
| Admin | You | Everything, including this checklist |
| Project Manager | Research managers, QA leads | Create and configure projects, run bots, manage issues, sign off |
| Internal Tester | Testers, survey authors | Test, report and work on issues in projects they are assigned to |
Duplicate a default role before you change it (Duplicate a Role), so you can always compare with the original. Typical additions: a Client role that may read and comment on issues but not change the project, and a Survey Author role that may close issues but not sign off. See Roles and permissions, Manage Locked Roles and Duplicate a Role.
Then invite the users and give each at least one role: Add User / Role to SurveyTester. Users can belong to several companies and are deactivated per company; a deactivated user keeps their history but loses access.

Security settings in the same area. Set the company's password policy (length, character classes, expiry, inactivity). Companies with Azure AD or Active Directory can switch on SAML single sign-on with automatic user and group provisioning; then roles follow the directory groups and this step runs itself.
2. Folder structure
Projects live in folders, and folders do more than tidy up: they are the scope for result-filter templates and for AI engine restrictions, and a role can be given access per folder. Design the tree along the way your company works, for example by client, by business unit or by year, and keep it shallow: two levels are enough for most companies. See also Who has access to my projects?.
3. Project types with classification fields
A project type (shown as Project Template in the Create Project dialog) bundles everything a project inherits at creation: the classification fields every issue is tagged with, the automatic checks and what they report, the end-page identifiers and the market and language questions. It is the most important setting on this list, because it decides how issues are sorted, filtered, exported and closed for years to come.
Per project type you define:
- Classification fields and their values, for example Severity (blocker, major, minor, cosmetic), Area (text, routing, layout, data) and Status (open, fixed, verified, rejected). See Classification Fields.
- Closing values. Mark the values that mean "this issue is done", for example verified and rejected. SurveyTester derives the open/closed state of every issue from them, so the open-issues badge, the sign-off warning and Insights all agree.
- Which fields appear on the Issues page and in which order: Company Setting for Fields on the Issues Page.
- Market and language questions. Name the survey questions that carry the market or language, so SurveyTester can assign test runs to markets even when the link does not.
- End-page identifiers. Keywords, redirect URL patterns or page names that mean Complete, Screenout, Quota full or Early complete for all projects of this type. Project managers can still refine them per project.

Tip
One project type per way of working, not per client. A "Standard QA" type and a "Client review" type with a reduced field set usually cover a whole company. Many types mean many filter templates and many exports to maintain.
4. Auto-Detect and personal-data settings
The automatic checks run after every test run and report their results as findings. Which checks run is set at three levels: company, project type and project; the more specific level wins. Start at company level with the checks everyone wants (spell check, visible HTML, unresolved piping, empty and duplicate labels, missing images, wrong-language text) and switch off per project type what does not apply, for example brand language checks for a type used only for internal surveys. See Auto Detect Issues.
The personal-data detection flags pages that ask for or display personal data, in two levels: simple (name, e-mail, phone, address) and extended for the special categories of the GDPR (health, religion, political opinion and others). Decide per company which level your projects need; privacy officers usually want extended on everything. The GDPR sub-processor register SurveyTester publishes is the document to hand them when they ask where the data goes.

5. Company dictionary
The spell check compares every label against the language's dictionary plus your Company Dictionary. Fill it before the first project with the words the spell check would otherwise report in every run: brand and product names, client names, abbreviations, industry terms. Later entries arrive on their own when testers decline a spelling finding with a reason such as "brand name"; review that inflow now and then. Brand entries also feed the brand language check, which reports a brand written in the wrong casing or spelling. See Company Dictionary and Spell check.
6. AI engines and features
AI in SurveyTester is opt-in and granular. Nothing is sent to a language model until an administrator has:
- Accepted an engine. Either from the SurveyTester catalogue (hosted, no key needed), with your own key for a vendor, or any OpenAI-compatible endpoint including a model hosted in your own data centre.
- Set a company default and, if needed, restricted engines per folder or project type.
- Decided per feature whether it uses the default engine, a specific engine, or stays off: generic survey parsing for unknown platforms, test case generation, AI auto answers, project import text analysis, image recognition and questionnaire document analysis.
Usage is metered per project, user, feature and model under AI Usage, so costs can be charged back. See AI Administration & Usage Controls.

Tip
Companies with strict data policies run two configurations: a catalogue engine hosted in the EU for test case generation and auto answers, and questionnaire analysis pinned to an internal model or switched off. "Off" is a real setting: there is no fallback to another engine.
7. Templates the project teams will see
Templates turn your decisions into defaults that appear in every new project:
- Result-filter templates. Templates are saved by the users themselves, from any project's Result Filter dialog, and can be shared with others and scoped to a folder or project type. Encourage the team leads to save the filters everyone uses daily (open blockers, issues since the last milestone, runs of one test case) as shared templates: the Create Project dialog then offers the matching ones to every new project. See Result Filter.
- Test plan templates. The test plan is the project's sign-off checklist. Start from the SurveyTester default of 84 items in 13 phases and remove or add items to match your QA process; the project team loads the template with one click under Project Details › Test plan.
- Mail templates. The texts of the e-mails SurveyTester sends on your company's behalf.
- Forms. Custom forms per company for information that does not fit the standard fields, with Excel export. See Custom Forms, Usage and Export Forms.

8. Extension rollout and notification defaults
Every tester needs the SurveyTester browser extension in Chrome or Edge. In managed environments, add it to the browser policy so it installs for everyone; otherwise send the installation article along with the invitation: Installing the SurveyTester Extension and Browser Extension.
Notifications are per user, but roles carry the defaults: which events a new holder of the role is subscribed to (new issues, phase changes, sign-off). Set them so that survey authors hear about issues in Script Update Needed and project managers about sign-offs, and nobody gets every event. See Notifications and Subscriptions.
Hand-over to the project teams
With the eight points done, a project manager can create a project in two minutes and inherits everything above: the right template, the right checks, the right filters and an AI policy the privacy officer has signed. Send them Best practices: from a new project to sign-off and review this checklist once a quarter: new clients bring new brand names, new teams bring new roles, and the AI catalogue changes.
Key takeaway
Set up roles before users, project types before projects, and dictionary and AI policy before the first bot run. Each of these settings is cheap to make once and expensive to retrofit across running projects.
