TS-C (NCCT) common mistakes
TS-C · Understand the traps and how to avoid them.
Answering access questions by talking about license levels (Creator/Explorer/Viewer) when the question is really about site roles and project permissions.
The admin UI puts license tier and site role side by side and the names overlap, so candidates collapse them into one idea and assume 'giving them a Creator license' also gives them access to a project.
What to do instead
Hold three separate layers: license level = capability ceiling, site role = site-wide scope (e.g. can they publish at all, can they administer), project permissions = which content they can actually see or change. For each scenario, ask 'is this a capability limit or an access limit?' and resolve using the most restrictive of the three.
Troubleshooting 'user can't open the dashboard' as a workbook-only permissions problem, ignoring the published data source the workbook is built on.
After publishing, a workbook looks like a single object in the UI, and the dependency on a separate published data source with its own permissions and embedded credentials is invisible unless you go looking.
What to do instead
Trace the chain: workbook permission → published data source permission → the connection credentials that data source runs as. A user can have View on the workbook and still get an error because they lack Connect on the data source.
Fixing a single project's access problem by changing permissions at the site or server (top) level of the content hierarchy.
Top-level settings are the easiest to find and 'obviously' fix everyone at once, but candidates forget permissions flow downward and that broad grants are painful to unwind.
What to do instead
Apply permissions as low in the hierarchy as the requirement allows - project level for most access decisions - and use permission locking on child projects/content so a later top-level change cannot silently widen access. Justify any server- or site-level grant explicitly.
Designing sites and projects around the organisation chart (one project per department) instead of around permission boundaries and content ownership.
Departments are the mental model people bring from file shares, so the structure feels natural even though it produces projects where nobody has a clean owner and permissions get re-granted individually.
What to do instead
Draw the boundary at 'who must see this' and 'who publishes here'. One project per access boundary, with a named owner and a group-based permission rule; use tags or nested projects for topical grouping rather than permissions.
Sizing the deployment from the number of licensed users alone and treating extract refresh load, background job concurrency and data volume as an afterthought.
Licence count is the number on the quote, so it anchors the whole plan; scheduled refreshes and interactive query concurrency only show up after go-live when the schedule collides.
What to do instead
Build a workload profile before sizing: how many extracts, how often, at what time, how large, plus peak concurrent viewers. Stagger refresh windows, size background processing capacity to the refresh queue, and prove the profile in a non-production environment with production-like data.
Accepting install defaults for service accounts, authentication, and transport security, planning to 'harden it later'.
The installer's default path is the fastest route to a running system, and 'later' never arrives once users are on it; retrofitting identity and certificates on a live system requires downtime nobody schedules.
What to do instead
Decide before install: dedicated service/run-as accounts (not personal or built-in accounts), the external identity store you will actually use, and TLS certificates with a full chain on every node. Write these into the build checklist so the first install is already the compliant one.
Going live after testing only with local/test accounts, without a round-trip test of the real identity store and certificate chain from a client machine.
Local accounts work instantly in a lab, and SSO and TLS failures are usually invisible from the server itself - they only surface from a browser on a different machine.
What to do instead
Before go-live, test with a real directory user: import a group, sign in through the actual SSO flow, and load the site from an outside client to confirm the certificate chain and hostname. Include a failed-login and expired-certificate scenario in the test plan.
Diagnosing a failed scheduled refresh by reopening the workbook in the authoring tool rather than reading the background job/task status and server logs.
The symptom is reported against the workbook, so candidates inspect the workbook; the actual failure cause (credential expiry, connection, resource contention) is recorded on the server side.
What to do instead
Start at the task/job history: identify the failing task, read its status message, then the corresponding log entries. Classify the failure as credential, connectivity, data/query, or resource before changing anything, and fix the class you found.
Treating 'a backup file exists' as proof of recoverability, with no restore ever attempted and no record of what the backup excludes.
Backup runs are easy to schedule and report green; restore is only exercised during an incident, when nobody has time to discover the gaps.
What to do instead
Run a scheduled restore into a non-production environment and record the time taken. Document what the backup does not cover (external assets, certificates, customisations) and where those are separately stored.
Granting site administrator or Creator-level rights broadly to clear the support queue.
It removes the immediate tickets, and the cost - a large population who can change site settings, publish, or see content they should not - is invisible until an audit or an incident.
What to do instead
Apply least privilege: grant through groups at project level for the specific need, keep the site administrator list short and reviewed on a cadence, and route residual requests through a documented exception with an owner and an expiry date.
Making governance claims about content quality, stale content, or who viewed what from memory instead of from usage/audit data.
Audit and usage views are a separate reporting surface from the admin screens candidates study, so they get treated as optional rather than as the evidence base for governance decisions.
What to do instead
Know where access and usage records live and use them: identify stale or unused content and orphaned owners (content owned by disabled accounts) from usage data, and set a review cadence so ownership transfers happen before accounts are removed.