Tableau Quiz: Url Actions
10 questions · exam conditions
0:00
Url ActionsQuestion 1 of 10

An external fulfillment application accepts a URL in the form https://fulfill.example.com/batch?ids=A12|B34|C56. Users must be able to select several order marks in Tableau and send all selected Order ID values in one URL.

How should the URL action be configured?

Insert Order ID once, disable multiple values, and use the pipe character as the URL escape character.
Insert three Order ID placeholders, enable URL encoding, and separate the placeholders with pipe characters.
Insert Order ID once, run the action on Menu, and set the browser target to a new tab.
Insert Order ID once, allow multiple values, and specify the pipe character as the item delimiter.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Url Actions

Practice Url Actions 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 Url Actions, 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

An external fulfillment application accepts a URL in the form https://fulfill.example.com/batch?ids=A12|B34|C56. Users must be able to select several order marks in Tableau and send all selected Order ID values in one URL.

How should the URL action be configured?

  1. Insert Order ID once, disable multiple values, and use the pipe character as the URL escape character.
  2. Insert three Order ID placeholders, enable URL encoding, and separate the placeholders with pipe characters.
  3. Insert Order ID once, run the action on Menu, and set the browser target to a new tab.
  4. Insert Order ID once, allow multiple values, and specify the pipe character as the item delimiter. (correct answer)
Explanation: When a Tableau URL action needs to pass multiple selected values to an external system, the key setting to focus on is how Tableau handles that multi-value output — specifically, the delimiter configuration. Tableau's URL actions let you insert a field placeholder like <Order ID> once in the URL string. When a user selects multiple marks, Tableau can automatically repeat that field's values and join them with a character you specify as the item delimiter. Setting the delimiter to the pipe character | produces exactly the format the fulfillment application expects: ids=A12|B34|C56. This is what option D describes, making it the correct configuration. Option A fails because "disabling multiple values" is the opposite of what you need — it would force the action to pass only a single Order ID regardless of how many marks are selected. The pipe character is a delimiter, not a URL escape character, so the terminology is also wrong. Option B misunderstands how placeholders work: inserting <Order ID> three times would hardcode exactly three values rather than dynamically scaling to however many marks the user selects. Option C is a red herring — the Menu trigger and browser target control when and where the URL opens, but they have nothing to do with consolidating multiple values into a single URL string. As a study tip, remember that Tableau URL actions have two separate concerns: how the URL is triggered (on select, menu, or hover) and how multi-value fields are formatted. Exam questions often mix these concepts to distract you — always ask yourself which concern the question is actually testing.

Question 2

A dashboard contains a summary bar chart and an order-detail sheet. Selecting a summary bar is used for analysis and must not open a website. Selecting a row in the detail sheet should open the corresponding order in an external system. A URL action currently uses all dashboard sheets as sources.

What is the most direct correction?

  1. Keep all sheets as sources, but change the action to run on Menu for the summary bar chart only.
  2. Set the action's source to selected sheets and include only the order-detail sheet as a source. (correct answer)
  3. Keep all sheets as sources, but remove Order ID from the summary chart's tooltip and level of detail.
  4. Set the summary chart as the action target and the order-detail sheet as its URL destination.
Explanation: When configuring URL actions in Tableau, the most important control you have is source sheet selection — which sheets trigger the action. By default, actions can be set to fire from all dashboard sheets, but that's often too broad. The fix should be surgical: limit the trigger to only the sheet where the behavior is desired. In this scenario, the URL action should only fire when a user selects a row in the order-detail sheet. The most direct correction is B — changing the action's source to selected sheets and choosing only the order-detail sheet. This is a single, targeted configuration change that solves the problem exactly: clicks on the summary bar chart no longer trigger the URL, while the detail sheet retains the intended behavior. A is tempting but fundamentally misunderstands how action triggers work. The "Menu" run option applies to the entire action, not per-sheet — you can't selectively assign run behavior to one source sheet within the same action. C attempts a workaround by removing Order ID from the summary chart's tooltip, which might prevent the URL from resolving, but it's an indirect hack that alters chart data rather than fixing the action's configuration. It could also break other functionality that depends on Order ID. D confuses sources with targets — action targets define where results appear, not what triggers the action. Setting the summary chart as a target doesn't prevent it from firing the URL. As a study tip: on Tableau exam questions about actions, always distinguish between source (what triggers), target (where filter/highlight results appear), and run on (hover, select, or menu). Most action problems hinge on correctly identifying which of these three needs adjustment.

Question 3

A view currently displays one mark per service team. Each mark aggregates many tickets, but the external service system accepts exactly one Ticket ID per URL. The requirement is that selecting a mark must open one clearly identified ticket, not an arbitrary aggregate or a list.

Which change is necessary before using Ticket ID in the URL action?

  1. Create a calculated field using MIN(Ticket ID) and insert it into the URL, so Tableau picks a deterministic ticket from each aggregated team mark.
  2. Allow multiple URL values and rely on the service system to ignore every ID after the first one in the list.
  3. Add Ticket ID to the view's level of detail so each selectable mark represents exactly one ticket and supplies an unambiguous value to the action. (correct answer)
  4. Add Ticket ID to the tooltip so that its value becomes uniquely available to the URL action when a mark is selected.
Explanation: When working with URL actions in Tableau, the critical concept is granularity: a URL action can only pass a clean, single value if the mark it fires from represents exactly one row at that field's level of detail. If a mark aggregates many rows, any field not in the view's level of detail becomes ambiguous — Tableau doesn't know which underlying value to send. That's precisely why C is correct. Adding Ticket ID to the view's Level of Detail shelf forces each mark to represent a single ticket. The aggregation problem disappears at the source: instead of one team-level mark hiding dozens of ticket IDs, you now have one mark per ticket, so the URL action always receives an unambiguous value. A is tempting because MIN(Ticket ID) does produce a deterministic, non-null value — but "deterministic" isn't the same as "meaningful." Picking the minimum ID from an aggregated group is essentially arbitrary from a business perspective; you're not selecting a ticket, you're selecting a random one that happens to sort first. The requirement explicitly rules this out. B describes a workaround that depends entirely on the external system's behavior, which you cannot control or guarantee. Relying on downstream systems to silently discard values is fragile and violates the requirement for a clearly identified ticket. D is a common misconception: adding a field to the Tooltip shelf does not make it available to URL actions. Tooltip only controls what's displayed on hover; it has no effect on action field resolution. Your study tip: whenever a URL action question mentions aggregated marks, immediately think about granularity. The fix is almost always structural — change what the mark represents, not how you format the value you're extracting from it.

Question 4

A single-select Fiscal Year filter applies to the worksheet that triggers a URL action. The selected mark does not include Fiscal Year in its dimensions. An external report must open as https://reports.example.com/summary?year=<current filtered year>.

Which approach preserves the existing mark granularity while sending the required year?

  1. Add Fiscal Year to Detail on the source sheet, then insert the resulting mark-level dimension into the report URL.
  2. Insert the Fiscal Year filter's current value into the URL using the action's available field placeholders, avoiding changes to mark granularity. (correct answer)
  3. Insert YEAR(TODAY()) into the URL, because the active dashboard filter is assumed to match the current calendar year.
  4. Use a dashboard filter action targeting the external report and map its year field to the Fiscal Year dimension.
Explanation: When working with URL actions in Tableau, the core challenge is passing dashboard-level context — like a filter value — into an external URL without disrupting how marks are structured on the source sheet. This question tests whether you understand the difference between mark-level dimensions and dashboard filter values, and how URL actions can access each. Tableau's URL actions support field placeholders that can reference the current filter value on a sheet, not just dimensions encoded in the mark itself. This means you can insert the active Fiscal Year filter value directly into the URL without touching the mark's granularity at all. That's exactly what B describes — it's the cleanest, most targeted solution because it uses the mechanism Tableau already provides for this purpose. A is tempting but introduces unnecessary side effects. Adding Fiscal Year to Detail changes the mark structure, potentially increasing granularity and breaking existing aggregations or visual behavior. The question explicitly asks you to preserve mark granularity, so this approach fails that requirement even if it technically passes the value. C is a logic error. The dashboard's Fiscal Year filter is a user-selected value that may or may not align with the current calendar year — replacing it with YEAR(TODAY()) hardcodes an assumption that could easily be wrong for any historical or future fiscal period a user selects. D misunderstands the mechanism entirely. Dashboard filter actions communicate between Tableau sheets or data sources, not external URLs. You cannot use a filter action to pass parameters to an outside web report. The key study tip: when a URL action needs dashboard-level context that isn't in the mark, reach for filter-value placeholders — never restructure the view just to expose a field.

Question 5

A dashboard links selected customer marks to https://support.example.com/search?customer=. Customer names can contain spaces, ampersands, and slashes, such as North/West & Co. The support site expects the customer name as one query-string value.

Which URL action configuration most reliably sends the selected customer name without changing its meaning?

  1. Append the inserted Customer Name field and enable Allow Multiple Values with an ampersand delimiter.
  2. Append the inserted Customer Name field and enable URL Encode Data Values for the action. (correct answer)
  3. Append the inserted Customer Name field and replace spaces with plus signs in a calculated field.
  4. Append the displayed customer label and place quotation marks around the inserted field placeholder.
Explanation: When configuring URL actions in Tableau, the core challenge is ensuring that special characters in field values don't break the URL structure. Characters like spaces, ampersands (&), and slashes (/) all carry special meaning in URLs — an ampersand signals a new query parameter, a slash separates path segments — so a raw customer name like North/West & Co would corrupt your URL entirely if passed unmodified. The solution is URL encoding, which converts special characters into percent-encoded equivalents (& becomes %26, / becomes %2F, spaces become %20). Enabling URL Encode Data Values in option B tells Tableau to apply this transformation automatically before appending the field value, preserving the customer name's meaning while keeping the URL syntactically valid. This is the most reliable, comprehensive approach. Option A fails because the "Allow Multiple Values" setting with an ampersand delimiter is designed for passing multiple selected marks, not for encoding a single value — it would actually introduce additional ampersands, further breaking the URL. Option C is a partial fix at best. Replacing spaces with plus signs only addresses one character type and ignores slashes, ampersands, and other problematic characters still present in the name. Option D is a misconception — wrapping a placeholder in quotation marks has no effect on URL parsing. URLs don't recognize quotation marks as delimiters for field values; the special characters still corrupt the query string. Study tip: Whenever a Tableau URL action question involves field values containing special characters, your instinct should be to look for the URL Encode Data Values option — it's Tableau's built-in, catch-all solution for this exact problem.

Question 6

An external application requires authentication. A developer proposes placing a permanent privileged API token directly in a Tableau URL action, such as https://app.example.com/case/123?token=SECRET, so every viewer can open the application.

What is the most appropriate design decision?

  1. Place the token in a hidden calculated field, because values not shown in the visualization cannot be inspected by viewers.
  2. URL-encode the token, because encoded query-string values are protected from browser history and server logs.
  3. Store the token in a Tableau parameter and hide its control, so the published URL action keeps it confidential.
  4. Do not embed the secret in the URL action; instead, link to an authenticated endpoint or secure intermediary that handles per-user authorization. (correct answer)
Explanation: When a question involves credentials, tokens, or secrets appearing in Tableau URL actions, shift your thinking from "how can I hide this?" to "should this be here at all?" Security questions on the Tableau exam often test whether you recognize that obscuring a secret is not the same as protecting it. Option D is correct because any secret embedded in a URL is fundamentally exposed — it appears in browser history, server access logs, network proxies, and can be read by anyone with access to the Tableau workbook's action configuration. The right architecture removes the secret from the URL entirely, routing users through an authenticated endpoint or OAuth-based intermediary that issues per-user, scoped credentials. This way, no permanent privileged token ever travels through a URL. Option A is a common trap: calculated fields — hidden or visible — are not encrypted. Anyone with download permissions or Tableau Desktop access can inspect the workbook's data model and extract the value. "Hidden" means visually absent, not protected. Option B mistakes encoding for encryption. URL-encoding transforms characters into percent-encoded equivalents (e.g., %3D) for safe transmission, not for confidentiality. The token remains fully readable in plaintext to anyone who decodes it — which any browser or log parser does automatically. Option C is similarly flawed. Tableau parameters are stored in the workbook XML in plaintext. Hiding the parameter control only removes the UI element; it does not prevent the value from being extracted by inspecting the published workbook file. Your study tip: whenever you see a question asking how to hide a secret inside Tableau, the correct answer almost always redirects you outside Tableau to a proper authentication layer. Obscurity is never a substitute for genuine access control.

Question 7

Each supplier record contains a Website value. Some values begin with https://, while others contain only a host name such as vendor.example.com. Selecting a supplier should open that supplier's own site rather than append the value to one fixed domain.

Which design is most appropriate?

  1. Use the raw Website field as a query parameter after a fixed company URL and enable multiple values.
  2. Place https:// before the Website placeholder in the action, including for values that already contain a protocol.
  3. Use the supplier name as the URL host and retain Website only as a label in the tooltip.
  4. Create a calculated field that normalizes each value to a complete URL, then insert it as the action's URL. (correct answer)
Explanation: When working with URL actions in Tableau, the core challenge is ensuring every generated URL is valid and complete — regardless of inconsistencies in the underlying data. That's exactly what this question tests. The fundamental problem here is that your Website field is inconsistent: some values already include https://, others don't. Any hardcoded URL action that ignores this variation will either break links or produce malformed addresses. The cleanest solution is D — creating a calculated field that normalizes every value into a proper URL before it ever reaches the action. Using logic like IF LEFT([Website], 8) = "https://" THEN [Website] ELSE "https://" + [Website] END, you guarantee every row produces a working link, and your URL action simply inserts that clean field as the full destination. A is wrong because appending a raw, inconsistent field to a fixed company domain defeats the entire purpose — you'd be sending users to your company's site with a garbled query string, not the supplier's actual website. B hardcodes https:// as a prefix for every record, which means values that already contain https:// would produce broken URLs like https://https://vendor.example.com. This is a classic trap: well-intentioned but data-unaware. C discards the Website field entirely as a navigable resource and invents a URL from the supplier name, which has no reliable relationship to actual domains and would generate broken or wrong destinations. Study tip: On Tableau exam questions involving dynamic URLs, always ask yourself whether the data is clean enough to use directly. If field values vary in format, the answer almost always involves a calculated field to normalize first — then wire the clean output into the action.

Question 8

A scatter plot supports exploratory selection. Users frequently click marks to inspect tooltips and do not want every selection to open an external profile. They should instead open the profile only by deliberately choosing a link presented for the mark.

Which URL action trigger best supports this interaction?

  1. Run on Select, because the external profile opens only after the mark remains selected.
  2. Run on Hover, because the user can inspect the tooltip before navigation begins.
  3. Run on Menu, because the user must choose the URL action from the mark's tooltip menu. (correct answer)
  4. Run on Select, but target a web page object so ordinary selections do not execute the action.
Explanation: When a question describes users who want deliberate, opt-in navigation rather than accidental redirects, you should immediately think about URL action triggers and which ones require explicit user intent. The three available triggers — Select, Hover, and Menu — differ in how much friction they introduce before navigation fires. Menu is the most deliberate: when a URL action is set to run on Menu, Tableau adds a clickable link inside the mark's tooltip. The user must open the tooltip and consciously click that link. Nothing happens from a casual click or mouseover alone. This matches the passage perfectly — users want to explore marks freely without triggering navigation, but still have a path to the external profile when they choose it. C is the correct answer. A is tempting because "Select" sounds controlled, but a URL action on Select fires the moment a mark is clicked — which is exactly what the passage says users don't want. Every exploratory click would open the external profile. D compounds the same misunderstanding: targeting a web page object changes where the URL loads, not when the action fires. A Select trigger still fires on every click regardless of the target object, so accidental navigation remains a problem. B is worse than Select — Hover fires even before the user fully commits to a mark, so it would trigger navigation the moment someone mouses over a dot, making exploration nearly impossible. As a study tip, remember this pattern: Menu = user chooses; Select = user clicks; Hover = user passes over. On the Tableau exam, whenever a scenario emphasizes avoiding unintentional navigation, Menu is almost always the right trigger.

Question 9

A dashboard has a string parameter named Documentation Release. Users change it among values such as 2025.4 and 2026.1. A Help mark should open https://docs.example.com/releases/<release>/overview, using the current parameter value even though that value is not represented by the selected mark.

How should the URL action be built?

  1. Insert the Documentation Release parameter into the release segment of the URL used by the Help mark. (correct answer)
  2. Insert the displayed mark label into the release segment and synchronize that label with the parameter caption.
  3. Add Documentation Release as a filter on the Help sheet and insert the resulting mark count into the URL.
  4. Create a filter action that passes Documentation Release from the Help mark to the documentation website.
Explanation: When building URL actions in Tableau, the key question is always: where does the dynamic data come from? URL actions can draw from fields on the sheet, but they can also draw directly from parameters — and knowing that distinction is what this question tests. Parameters are first-class citizens in Tableau URL actions. You can insert a parameter directly into any segment of a URL using the parameter insertion syntax, just as you would insert a field. This means the URL updates automatically whenever the user changes the parameter value — no marks, no aggregations, no workarounds needed. Choice A does exactly this: it places the Documentation Release parameter into the release segment, producing something like https://docs.example.com/releases/2025.4/overview dynamically. This is the correct, straightforward approach. Choice B is tempting but flawed. Mark labels reflect data on the sheet, and there's no reliable built-in mechanism to "synchronize" a label with a parameter caption — you'd be manufacturing a brittle workaround where none is needed. Choice C is a red herring that misuses aggregation; the number of marks matching a filter has nothing to do with constructing a version string like 2025.4. Choice D misunderstands action types entirely — filter actions pass context between sheets within Tableau; they cannot transmit values to an external website URL. The study tip here: whenever a question asks you to embed a user-controlled value into a URL action, check first whether a parameter can do the job directly. Parameters bypass the need for that value to exist as a mark on the sheet, which makes them the cleanest solution in scenarios exactly like this one.

Question 10

A dashboard contains a Web Page object named Case Details. A partner site permits embedding, and selecting a case mark should refresh that object without opening another browser tab.

Which configuration satisfies the requirement?

  1. Create a URL action using the case URL and set its URL target to the Case Details web page object. (correct answer)
  2. Create a filter action targeting Case Details and add the partner domain to the filter's selected fields.
  3. Create a URL action using the case URL and set its URL target to a new browser tab.
  4. Create a parameter action targeting Case Details and assign the selected case URL to the object.
Explanation: When a dashboard contains a Web Page object, Tableau gives you the ability to load URLs directly inside that named object — but only through a specific action type and target setting. The key concept being tested here is how URL actions interact with named dashboard objects versus browser-level navigation. A URL action has a configurable URL Target that controls where the URL opens: a new browser tab, a new browser window, or a named Web Page object on the dashboard. When you set the target to the Case Details object by name, clicking a case mark loads the URL inline, refreshing that object in place — exactly what the requirement describes. That makes A the correct answer. B is wrong because filter actions filter data in sheets, not load external URLs into Web Page objects. The partner domain isn't a "field" you can filter on — this answer conflates two entirely different action mechanisms. C describes a URL action configured to open in a new browser tab, which directly contradicts the requirement. The partner site permitting embedding is a red herring if you don't use the embedded target option — opening a new tab defeats the purpose. D is wrong because parameter actions assign values to Tableau parameters, which then drive calculations or filters. They have no mechanism to tell a Web Page object what URL to display. Study tip: Whenever a Tableau question mentions a Web Page dashboard object and in-dashboard navigation, immediately think "URL action + named object target." That pairing is the only built-in mechanism for refreshing a Web Page object without leaving the dashboard.