Tableau Quiz: Comments And Subscriptions
10 questions · exam conditions
0:00
Comments And SubscriptionsQuestion 1 of 10

A sales manager comments on a published Tableau view and @mentions a regional contractor. The contractor has a Tableau account on the site but has not been granted access to the workbook.

What is the most likely result of the manager's action?

The mention grants temporary view access, allowing the contractor to open the workbook from the notification.
The mention may generate a notification, but it does not grant the contractor permission to open the workbook.
The comment becomes private because Tableau automatically restricts mentioned comments to their named recipients.
The comment cannot be saved because every mentioned user must already have access to the workbook.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Comments And Subscriptions

Practice Comments And Subscriptions in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Comments And Subscriptions, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A sales manager comments on a published Tableau view and @mentions a regional contractor. The contractor has a Tableau account on the site but has not been granted access to the workbook.

What is the most likely result of the manager's action?

  1. The mention grants temporary view access, allowing the contractor to open the workbook from the notification.
  2. The mention may generate a notification, but it does not grant the contractor permission to open the workbook. (correct answer)
  3. The comment becomes private because Tableau automatically restricts mentioned comments to their named recipients.
  4. The comment cannot be saved because every mentioned user must already have access to the workbook.
Explanation: Whenever you see a question about Tableau collaboration features, focus on the distinction between communication tools and permission systems — they operate independently of each other. In Tableau Server and Tableau Cloud, @mentions in comments are a notification feature, not an access-control mechanism. When a manager @mentions a contractor in a comment, Tableau may send that user a notification (such as an email or in-app alert). However, the contractor's ability to actually open and view the workbook is governed entirely by the site's permission settings — content permissions that must be explicitly granted by an administrator or content owner. A mention does nothing to modify those permissions. This makes B correct: the notification may reach the contractor, but without proper access rights, they cannot open the workbook. A is wrong because Tableau does not have a "temporary access" feature triggered by mentions — no such mechanism exists in the platform's permission model. C is wrong because comments are not automatically made private based on @mentions; visibility of comments follows the workbook's existing access settings, not the identity of mentioned users. D is wrong because Tableau does not block you from saving a comment simply because a mentioned user lacks access — the platform allows the comment to post regardless of the mentioned person's permissions. A reliable study tip: on Tableau exam questions, treat collaboration features (comments, alerts, subscriptions) and permission features (site roles, content permissions) as two completely separate systems. A question that tries to blend them — suggesting one affects the other — is almost always a trap.

Question 2

An analyst filters a published view to the West region and selects several unusually low-profit marks. Before asking a colleague to investigate, the analyst adds a comment and includes a snapshot of the current view.

What is the primary governance benefit of including the snapshot?

  1. It permanently changes the workbook's default filters so all later users begin with the West region.
  2. It preserves the relevant visual context with the comment without changing the published workbook's default state. (correct answer)
  3. It exports the underlying rows into the comment so the colleague can analyze them without view access.
  4. It creates a scheduled subscription that sends the same filtered state whenever the data source refreshes.
Explanation: When you see a question about Tableau Server's annotation and sharing features, focus on what each tool actually does to the published workbook versus what exists only in the collaboration layer. That distinction is the heart of this question. Adding a snapshot to a comment captures a static image of the current view — including your active filters and selected marks — and attaches it directly to that comment thread. This means your colleague immediately sees which marks concerned you and why, without you needing to describe the visual in words. Critically, the published workbook itself is untouched: its default filters, layout, and state remain exactly as the original author defined them. That's the governance benefit B describes — preserving visual context without altering the workbook's default state for other users. A is wrong because comments and snapshots have no mechanism to rewrite a workbook's default filters. Changing defaults requires editing and republishing the workbook itself, which is a separate, permission-gated action. C is wrong because a snapshot is literally a screenshot — a rasterized image — not a data export. Underlying row-level data is never embedded in a comment, and accessing it still requires proper view or data permissions. D is wrong because subscriptions are a separate feature entirely, configured through the subscription menu with scheduled delivery settings. Attaching a snapshot to a comment does not trigger, create, or schedule anything. As a study tip, watch for answer choices that conflate Tableau's distinct features — comments, subscriptions, permissions, and publishing are separate systems. When a question describes one workflow, verify that the answer stays within that feature's actual scope.

Question 3

A dashboard applies user-based data security so regional managers see only their assigned regions. An authorized workbook owner creates a subscription for several managers who already have permission to view the dashboard.

Which outcome should the owner expect?

  1. Every manager receives the owner's regional data because the owner created the subscription.
  2. Every manager receives an unfiltered dashboard because subscription images cannot apply user-based security.
  3. Each manager's subscription is rendered according to that recipient's applicable data access and permissions. (correct answer)
  4. The subscription is rejected because Tableau does not permit subscriptions to user-filtered dashboards.
Explanation: When Tableau renders a subscription, it doesn't use the creator's identity to generate each recipient's view — it renders the content as each recipient. This is the core concept being tested: how Tableau handles data security in subscriptions when row-level or user-based filters are in place. Because the dashboard already applies user-based security, each manager's subscription email reflects only the data that manager is permitted to see. Tableau evaluates permissions at render time for each individual recipient, so the security model travels with the content. This makes C the correct answer — each manager receives a subscription image filtered to their own data access, exactly as if they had opened the dashboard themselves. Answer A gets the logic backwards. The subscription owner's permissions don't override or replace the recipients' permissions. The owner's role is simply to schedule the subscription, not to determine whose data appears in it. Answer B is a common misconception worth flagging: subscription images absolutely can reflect user-based security because Tableau renders them per-recipient, not as a single static snapshot for everyone. Answer D describes a restriction that doesn't exist in Tableau — subscriptions to user-filtered dashboards are fully supported and are, in fact, a common enterprise use case for delivering personalized snapshots at scale. Study tip: On Tableau exam questions involving subscriptions, alerts, or embedded views, always ask yourself whose identity is used at render time. Tableau's security model is recipient-centric for subscriptions — the owner schedules, but each viewer's permissions govern what they actually see.

Question 4

An analyst has permission to subscribe other Tableau users to a workbook. Executives need a weekly dashboard image, but one executive has not been granted access to the workbook.

Which action best follows Tableau sharing and governance principles?

  1. Subscribe every executive immediately because receiving an image does not require access to the underlying content.
  2. Post the image as a comment because comment recipients receive access even when workbook permissions are absent.
  3. Subscribe only the analyst and create an automatic email-forwarding rule to bypass Tableau content permissions.
  4. Grant the missing executive appropriate workbook access, then include that executive in the Tableau subscription. (correct answer)
Explanation: When a question involves subscriptions and sharing in Tableau, you should immediately think about content permissions as a prerequisite — Tableau's governance model requires that a user have appropriate access to content before they can receive scheduled deliveries of it. Subscriptions are not a backdoor around permissions; they are an extension of them. The right path here is D: first grant the missing executive the appropriate workbook permissions, then include them in the subscription. This respects Tableau's permission hierarchy and keeps your organization's data governance intact. The executive gets the content they need, and access is tracked and controlled properly. A is a common misconception trap. Receiving a dashboard image via subscription still requires the recipient to have workbook access — Tableau verifies permissions before sending. You cannot subscribe someone to content they cannot view. B is similarly flawed. Posting an image as a comment does not grant workbook access to comment recipients. Comments are a collaboration feature, not a permissions mechanism. The executive would see a notification but still lack access to the underlying content. C describes a governance violation. Creating an email-forwarding workaround deliberately circumvents Tableau's permission controls. Even if it worked technically, it undermines your organization's security policies and removes any audit trail for who is accessing sensitive data. On the exam, any answer that involves bypassing built-in controls should be an immediate red flag. Study tip: On Tableau governance questions, always ask yourself — does this answer respect or circumvent the permissions model? Answers that route around access controls are almost always wrong, regardless of whether they would technically work.

Question 5

A project permission rule allows a user to view a workbook and view existing comments but denies the capability to add comments. Other users have already posted several comments on one of the workbook's views.

Which interaction should the user expect?

  1. The user can read the existing comments but cannot add a new comment or reply to one. (correct answer)
  2. The user can reply to existing comments but cannot begin a separate comment thread.
  3. The user can add comments, but those comments remain visible only to workbook owners.
  4. The user cannot open the comments pane because viewing a workbook does not include comment access.
Explanation: When a question describes a combination of permissions in Tableau, your job is to identify exactly what each granted or denied capability controls — and nothing more, nothing less. In Tableau, "View Comments" and "Add Comments" are distinct, separately controlled capabilities. When a permission rule explicitly grants View Comments but denies Add Comments, the user can read any comments already on a view, but cannot contribute new ones in any form. Crucially, "adding a comment" covers both starting a new thread and replying to an existing one — replies are treated as new comment additions under the same capability. So the user can open the comments pane, read what others have written, and stop there. That makes A the correct answer. B is wrong because it implies a distinction between replying and starting a thread, as if replies require a lesser permission. Tableau does not split Add Comments into "reply" versus "new thread" sub-permissions — both actions fall under the same denied capability. C is wrong because Tableau has no mechanism that restricts comment visibility by role after posting. Comments are not silently scoped to owners; they are either postable or not. This answer invents a feature that doesn't exist. D is wrong because viewing a workbook and viewing comments are independent capabilities — a user can absolutely open the comments pane without having full workbook-editing rights. The View Comments permission is what unlocks pane access, and it is granted here. A useful study habit: when you see "denies X," ask yourself everything X covers. On Tableau permission questions, a single denied capability often blocks more actions than students initially expect.

Question 6

A finance director wants an email only when total overdue receivables exceed a defined threshold. The director does not want an email on days when the amount remains below that threshold.

Which approach most directly satisfies the requirement?

  1. Create a daily subscription and assume Tableau sends it only when the threshold value changes.
  2. Create a weekly subscription and enable comment notifications for the dashboard's discussion thread.
  3. Add a comment containing the threshold and @mention the director whenever the workbook refreshes.
  4. Use a data-driven alert on the threshold condition rather than relying on a routine scheduled subscription. (correct answer)
Explanation: When a Tableau question asks about conditional alerting — notifying someone only when a specific business condition is met — you need to distinguish between scheduled delivery (which sends content on a fixed cadence regardless of data) and event-driven alerting (which triggers only when a threshold is crossed). The finance director's requirement is explicitly conditional: send a notification only if overdue receivables exceed a threshold, and stay silent otherwise. This maps perfectly to data-driven alerts, which monitor a metric and fire an email the moment that condition becomes true. That's exactly what D offers — a targeted, condition-based trigger rather than a time-based one. Option A is tempting but wrong. Standard subscriptions send on a fixed schedule every time, unconditionally. Tableau subscriptions do not evaluate threshold logic; they don't "skip" sends when values haven't changed or fallen below a limit. Option B compounds the problem by switching to a weekly cadence and bolting on comment notifications — neither feature addresses the conditional requirement, and weekly frequency could delay a critical alert by days. Option C is a manual workaround, not a system-driven solution. It relies on a human noticing the value during a refresh and manually @mentioning the director, which is error-prone and defeats the purpose of automation entirely. Data-driven alerts are the correct Tableau feature here because they let you define a numeric condition (greater than, less than, etc.) and deliver a notification only when that condition is satisfied. Study tip: On the Tableau exam, whenever you see language like "only when," "only if," or "exceeds a threshold," that's a signal to think data-driven alerts — not subscriptions.

Question 7

A user can open a published live-connection dashboard by entering database credentials when prompted. The user then creates a weekly subscription, but Tableau cannot access the database when the scheduled job runs unattended.

What is the most appropriate explanation and remedy?

  1. Subscriptions run unattended and cannot prompt for credentials, so the publisher must configure a saved-credential or equivalent approved authentication method that supports scheduled access. (correct answer)
  2. Subscriptions rely on comment-session tokens for authentication, so the user should post a comment immediately before each scheduled delivery to refresh the session.
  3. Subscriptions can prompt recipients for credentials through email, so the recipient should reply to the subscription message with the required database password.
  4. Subscriptions exclusively support extract data sources, so the administrator must convert every live connection to a published extract before subscriptions can be enabled.
Explanation: When you see a question about Tableau subscriptions failing for live-connection data sources, anchor your thinking around one core principle: scheduled jobs run unattended. There is no user present, no browser session, and no mechanism to display a credentials prompt — so any authentication method that requires interactive input will silently fail. This is exactly why A is correct. Subscriptions are automated background jobs triggered by Tableau Server or Tableau Cloud on a schedule. When the job runs, it must be able to authenticate to the database entirely on its own. That requires a saved credential (stored in the user's account settings or via an OAuth token), an embedded data source credential, or a service account — something the server can use without human intervention. The distractors each represent a different misconception worth learning from. B invents a fictional concept called "comment-session tokens" — no such authentication mechanism exists in Tableau. C is similarly fabricated; subscriptions are outbound email deliveries, and replying to them does nothing whatsoever to the server or its database connections. D contains a grain of truth (extracts do avoid the live-connection credential problem because the data is already cached), but it overstates the constraint — subscriptions are not exclusively limited to extracts. Live connections work fine with subscriptions as long as proper saved credentials are configured. Study tip: On the Tableau exam, whenever you see a scenario involving scheduled tasks — subscriptions, extract refreshes, or alerts — immediately ask yourself, "Can this step happen without a human present?" If the proposed solution requires user interaction, it's almost certainly wrong.

Question 8

A team subscribes to a daily exception view and selects the option not to send the subscription when the view is empty. On Monday, the filters legitimately return no exception marks. On Tuesday, the data source is unavailable and the view cannot be rendered.

How should these two outcomes be interpreted?

  1. Both days are successful empty-view suppressions because no marks can be displayed in either case.
  2. Monday can be suppressed as an empty result, while Tuesday represents a rendering or subscription failure. (correct answer)
  3. Monday generates an error because empty views are invalid, while Tuesday sends the last successful image.
  4. Both days send blank images because the empty-view option affects only interactive browser sessions.
Explanation: Tableau's subscription system distinguishes between two fundamentally different reasons why a view might appear blank — and that distinction is exactly what this question tests. When you configure a subscription to suppress empty views, you're telling Tableau: "If the data legitimately returns no results, don't bother sending the email." That logic applies only when the view actually renders successfully and simply has nothing to show. Monday fits that profile perfectly. The filters run, the view loads, and the result is genuinely empty — no exception marks exist in the data. Tableau recognizes this as a valid empty result and correctly suppresses the subscription. Tuesday is an entirely different situation: the data source is unavailable, so the view cannot render at all. Tableau treats this as a failure — a broken subscription attempt — not as a legitimate empty view. This makes B the correct answer. Choice A collapses two distinct outcomes into one category. The fact that neither day displays marks doesn't make them equivalent — the reason matters. A rendering failure is not the same as an empty result. Choice C inverts Monday's behavior entirely; an empty view with suppression enabled is a success state, not an error. Tableau doesn't send the last cached image in this scenario, so Tuesday's description is also fabricated. Choice D misrepresents the feature entirely — the empty-view suppression setting applies directly to email subscriptions, not just browser sessions. A useful rule of thumb: on Tableau exam questions involving subscriptions, always ask yourself why the view is empty. A data-driven empty result and a system failure look the same to the recipient but are treated very differently by Tableau's subscription engine.

Question 9

A user comments on a dashboard every Monday and receives notifications when colleagues reply. The user assumes these interactions will also cause Tableau to email the dashboard image each Monday, but no image arrives.

What best explains the missing dashboard email?

  1. Reply notifications automatically replace any scheduled subscription for users who are active in a comment thread, suspending image delivery until the thread closes.
  2. A dashboard image is delivered only after the user resolves and deletes all open comments from the discussion pane, clearing the view for export.
  3. Comment participation and reply notifications are separate features from subscriptions; to receive a dashboard image, the user must explicitly create or be added to a subscription. (correct answer)
  4. Posting a comment initiates a pending subscription that is held until a site administrator reviews and approves the associated comment snapshot.
Explanation: Whenever you see a Tableau question about notifications and email delivery, pause and ask yourself: which specific feature is responsible for each behavior? Tableau has distinct, independent features that can seem related but don't automatically trigger one another. In Tableau, subscriptions are the dedicated mechanism for delivering scheduled dashboard images via email. You must explicitly create a subscription — or be added to one by an admin — and configure its schedule. Comment threads and reply notifications are a completely separate collaboration feature. They alert you when someone responds to your comment, but they carry no logic to generate or send dashboard images. Because the user in the passage never set up a subscription, no image arrives — which is exactly what answer C captures. Answer A invents a rule that doesn't exist: reply notifications don't "replace" or "suspend" subscriptions. There is no such interaction between these two features in Tableau. Answer B is equally fabricated — subscriptions are not gated behind resolving or deleting comments. A comment's status has no bearing on whether a subscription fires. Answer D describes a nonexistent admin-approval workflow; subscriptions don't enter a "pending" state waiting for administrative review of comment snapshots. The key study takeaway here is to treat Tableau features as siloed by default unless you have explicit knowledge that they integrate. On the exam, distractors often imply that two features automatically affect each other — that's usually the trap. When in doubt, ask: did the user actually configure the specific feature needed for that outcome? If not, the outcome won't happen.

Question 10

A workbook uses an extract scheduled to refresh at 6:00 a.m. A subscription sends the workbook at 6:05 a.m. On busy days, the refresh does not finish until 6:15 a.m., and recipients sometimes receive the prior day's figures.

Which change most directly addresses the problem?

  1. Coordinate the subscription to run after the extract refresh is expected to finish, allowing for refresh variability. (correct answer)
  2. Enable comments on the workbook so recipients can confirm whether the extract refresh completed successfully.
  3. Move the subscription to 5:55 a.m. so Tableau queues the email before beginning the extract refresh.
  4. Increase each recipient's workbook permissions so the subscription waits automatically for refreshed data.
Explanation: When managing Tableau Server workflows, timing dependencies between extract refreshes and subscriptions are a common source of stale-data problems. The core issue here is a race condition: the subscription fires at 6:05 a.m., but on busy days the extract doesn't finish until 6:15 a.m. — so the email goes out before fresh data is loaded. The most direct fix is to delay the subscription enough to reliably follow the completed refresh, while still accounting for variability in how long the refresh takes. That's exactly what A does: it reschedules the subscription to run after the refresh is realistically expected to finish, directly eliminating the timing gap. B is a trap because enabling comments gives recipients a way to report the problem after the fact, but does nothing to prevent stale data from being sent in the first place. C makes the problem worse — moving the subscription to 5:55 a.m. means it runs before the refresh even starts, guaranteeing yesterday's figures every day, not just on busy ones. D misrepresents how Tableau permissions work; recipient permissions control what data users can see, not how subscription delivery interacts with refresh completion. There is no native permission setting that makes a subscription "wait" for a refresh to finish. A is the correct answer because it tackles the root cause directly: the subscription simply needs a later start time that accounts for refresh variability. Study tip: On scheduling questions, always trace the sequence of events — refresh, then subscription. If the question describes a timing gap, the answer almost always involves adjusting that sequence, not adding a workaround downstream.