• Cert++
  • Practice
  • Certle
  • Review
  • Tracks
  • Checklist
  • Guides
  • Upgrade
Cert++
  1. Home
  3. Tableau Consultant

Tableau Consultant

Checklist progress

0/281Learned

Tableau Consultant

Study Checklist

  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Architect

Checklist progress

0/281Learned

  • Choosing between a governed operational-monitoring dashboard and an ad hoc, exploratory workbook given a described business need for real-time ops visibility versus open-ended discovery.
  • Determining when a stated self-service analytics requirement implies Explorer-level versus Creator-level licensing.
  • Identifying the authoring capabilities each Tableau site role (Explorer versus Creator) provides for self-service analytics.
  • Given a requirement to share dashboards with external, unauthenticated stakeholders, mapping the need to Tableau Public, embedded analytics, or Viewer licensing.
  • Evaluating the trade-offs of Tableau Public, embedded analytics, and Viewer licensing for sharing dashboards with external stakeholders.
  • Mapping a requirement for centralized, governed KPI reporting across many departments to Tableau's certified data source and content certification capabilities.
  • Mapping a requirement for field or mobile consumption of dashboards to Tableau Mobile capabilities.
  • Identifying the dashboard design constraints that follow from a mobile or field-consumption requirement.
  • Given a requirement for real-time operational visibility, identifying which Tableau capabilities (live connection, frequent extract refresh) address that need.
  • Given a requirement for stable historical reporting, identifying which Tableau capabilities (scheduled extract refresh, snapshots) address that need.
  • Recognizing when a predictive modeling requirement exceeds Tableau's native capabilities and requires an integration such as Einstein Discovery.
  • Recognizing when a what-if scenario simulation requirement exceeds Tableau's native capabilities and requires an integration such as R or Python.
  • Mapping a requirement to embed live, interactive Tableau content inside a third-party web or mobile application to Tableau's Embedded Analytics and Connected Apps capabilities rather than static exports.
  • Mapping a requirement for proactive, AI-driven metric monitoring and natural-language digests to Tableau Pulse rather than a manually built dashboard.
  • Mapping a requirement to extend a dashboard with custom, interactive components not natively available in Tableau, such as a custom input control or write-back widget, to Dashboard Extensions.
  • Mapping an accessibility requirement, such as screen-reader compatibility, to Tableau's accessible dashboard features.
  • Identifying the design constraints that accessible dashboard features impose on layout and interactivity.
  • Applying the best practice of identifying the primary audience and the decision a dashboard supports before beginning design.
  • Translating a requirement to 'compare performance across regions' into a specific chart type and calculation approach consistent with Tableau design best practice.
  • Applying best practice to translate a requirement to 'drill from summary to detail' into a specific Tableau technique such as hierarchies, drill-down actions, or dashboard navigation.
  • Recognizing when a stated analytical requirement actually implies a need for a calculated KPI or target rather than a simple aggregation, and how that should shape the data source design.
  • Translating an executive-level requirement for a single, glanceable headline metric into a best-practice KPI or 'big number' design rather than a dense multi-chart dashboard.
  • Translating a requirement to 'measure performance against a goal' into a reference line, band, or bullet-graph-style visualization consistent with Tableau design best practice.
  • Applying colorblind-safe palette best practice when translating a requirement to visually distinguish multiple categories.
  • Applying redundant encoding best practice when translating a requirement to visually distinguish multiple categories.
  • Translating a requirement to 'show part-to-whole composition' into an appropriate chart, such as a stacked bar or treemap, while avoiding a pie chart when the category count is high.
  • Applying best practice to avoid a dual-axis combination chart when two measures have incompatible scales, recommending an alternative such as small multiples instead.
  • Estimating migration effort and risk for a Tableau Server-to-Cloud project based on the complexity of an existing environment, such as custom authentication or embedded extensions.
  • Recommending Tableau Cloud over Tableau Server based on total cost of ownership when an organization lacks dedicated infrastructure staff to maintain on-premises servers.
  • Recommending the Tableau Content Migration Tool to plan and execute a structured Server-to-Cloud or Server-to-Server content migration rather than manual republishing.
  • Identifying the organizational factors, such as elastic scaling and reduced infrastructure ownership, that favor recommending Tableau Cloud over Tableau Server.
  • Identifying the organizational factors, such as strict network isolation or a custom authentication protocol, that favor recommending Tableau Server over Tableau Cloud.
  • Assessing a regulatory requirement that data remain within a specific country's borders to determine whether Tableau Server or Tableau Cloud is the appropriate recommendation.
  • Recommending a hybrid approach that uses Tableau Bridge to connect Tableau Cloud to on-premises data as an alternative to a full Tableau Server deployment.
  • Identifying authentication reconfiguration as a key step when planning a migration from Tableau Server to Tableau Cloud.
  • Identifying connection-type changes as a key step when planning a migration from Tableau Server to Tableau Cloud.
  • Identifying features that behave differently or are unavailable when moving from Tableau Server to Tableau Cloud, and how those differences affect a migration recommendation.
  • Recommending an upgrade cadence and strategy that matches an organization's risk tolerance, such as staying on a supported prior version versus always upgrading to the current release.
  • Identifying review of deprecated features as a planning step that should precede a Tableau Server upgrade.
  • Identifying extension compatibility review as a planning step that should precede a Tableau Server upgrade.
  • Identifying custom configuration review as a planning step that should precede a Tableau Server upgrade.
  • Recommending a staged or blue-green upgrade approach to minimize downtime for a business-critical, production Tableau Server environment.
  • Identifying full backups as a pre-upgrade validation step before a production Tableau Server upgrade.
  • Identifying test-environment validation as a pre-upgrade validation step before a production Tableau Server upgrade.
  • Determining when a Tableau Server upgrade requires a corresponding operating system or database version upgrade and how that dependency affects the plan.
  • Recommending how to schedule a Tableau Server upgrade around business-critical reporting periods, such as avoiding a fiscal close window.
  • Recommending a stakeholder communication plan as part of a Tableau Server upgrade.
  • Recommending a rollback strategy as part of a Tableau Server upgrade in case post-upgrade validation fails.
  • Assessing whether an existing data source's grain, such as monthly aggregates, can support a business requirement for daily-level analysis.
  • Determining whether existing data volume and structure will scale to a growing business requirement, such as adding new regions or business units.
  • Recognizing when a business need requires blending multiple existing data sources and evaluating whether a common key exists to support that blend.
  • Evaluating whether the existing data's field types, such as numeric values stored as text, need conversion before they can support required calculations.
  • Evaluating whether an existing data source's structure can support the row-level granularity required for a stated row-level security requirement.
  • Using Tableau's data lineage and impact analysis capabilities to trace a field back to its origin across multiple upstream transformation steps.
  • Using lineage information to identify which upstream data source changes will impact downstream workbooks and dashboards before making a change.
  • Identifying lineage gaps, such as undocumented transformations or orphaned data sources, that introduce risk before a project change.
  • Using column-level (field-level) lineage to determine exactly which downstream calculated fields and worksheets are affected by a proposed schema change.
  • Recognizing the limits of Tableau's automated lineage tracking for data sources built on custom SQL or file-based connections, and the added documentation needed to compensate.
  • Identifying excessive joins in an existing data structure as a performance risk.
  • Recognizing when an existing extract-based data source has grown too large and identifying enhancement strategies such as aggregation, extract filters, or incremental refresh.
  • Identifying opportunities to pre-aggregate or materialize data upstream in order to reduce calculation load on the Tableau side.
  • Evaluating whether an existing data structure's reliance on data blending, rather than relationships or joins, is creating unnecessary performance overhead.
  • Recognizing how denormalized versus normalized data structures create different performance trade-offs for a given analytical workload.
  • Evaluating whether stacked or nested custom SQL statements within a single data source are creating an unoptimized, non-pushdown-friendly query plan.
  • Evaluating whether complex calculated-field logic embedded at the data source level, rather than pushed upstream, is creating a performance risk across all dependent workbooks.

Recommend an appropriate data transformation strategy

0/7

  • Recommending Tableau Prep for a scenario involving a repeated, scheduled cleaning task versus a one-off transformation performed in Tableau Desktop.
  • Given multiple data sources that need standardized values before they can be combined, recommending a transformation strategy such as a Tableau Prep flow versus custom SQL.
  • Recommending an incremental refresh transformation strategy for a large, frequently updated data source.
  • Recommending whether to fix a data quality issue at its source or in Tableau based on governance and reusability needs.
  • Recommending Tableau Prep Conductor to schedule and orchestrate a recurring, multi-step transformation flow at scale rather than manually rerunning it in Desktop.
  • Recommending a pivot step to reshape wide-format source data, such as one column per month, into a long/tall format required for analysis.
  • Recommending a scripting step, such as TabPy or an R integration, within a Tableau Prep flow for a transformation not supported by native Prep steps.

Specify the requirements for minimum level of granularity

0/6

  • Determining the minimum grain a data source needs in order to support a stated set of required calculations and dimensions.
  • Given a report that must show both transaction-level detail and monthly aggregates, specifying the granularity the underlying data source needs.
  • Recognizing when insufficient granularity in a source dataset makes a specific analytical requirement, such as cohort analysis, impossible to fulfill.
  • Specifying the granularity required to correctly implement a Level of Detail expression for a given business question.
  • Determining how granularity requirements differ depending on whether the analysis will rely on table calculations versus Level of Detail expressions.
  • Specifying the granularity alignment required between a primary and secondary data source before they can be blended without introducing duplication or unmatched rows.

Implement RLS and an entitlement table

0/10

  • Designing an entitlement (security) table structure that maps users or groups to the data rows they are permitted to see.
  • Implementing row-level security using a data source filter driven by a calculated field that joins to an entitlement table.
  • Implementing row-level security with USERNAME() or ISMEMBEROF() functions evaluated against an entitlement table for individual-user versus group-based access.
  • Designing entitlement table maintenance for a hierarchical access scenario, such as a manager needing visibility into direct reports' data.
  • Choosing to implement RLS at the database level through a view or virtual connection data policy.
  • Choosing to implement RLS at the Tableau data source level using calculated field filters.
  • Troubleshooting a scenario where entitlement-table-driven row-level security is not restricting data as expected, such as due to a join mismatch or case-sensitive usernames.
  • Designing an entitlement table to support multiple, overlapping security rules, such as a user who needs access to several distinct regions.
  • Designing an automated process to sync an entitlement table from an authoritative source, such as an HR system or identity provider, to keep row-level security current.
  • Implementing row-level security through a virtual connection's centralized data policy so the entitlement rule is enforced consistently across every data source built on that connection.

Identify group functions versus user functions

0/7

  • Distinguishing ISMEMBEROF(), a group-based function, from USERNAME(), an individual-user-based function, in an RLS calculation.
  • Identifying when ISMEMBEROF() is appropriate versus USERNAME() in an entitlement-table-driven RLS calculation.
  • Identifying scenarios where using group functions reduces entitlement table maintenance compared to relying on individual user-level functions.
  • Recognizing the performance and maintenance trade-offs between group functions and user functions as the number of users grows.
  • Determining when security should follow Tableau Server or Tableau Cloud group membership rather than individual user identity, and selecting the corresponding function.
  • Troubleshooting incorrect row-level security results caused by confusing group-membership logic with individual-user logic, such as with nested groups.
  • Distinguishing identity-display functions, such as FULLNAME(), from identity-comparison functions, such as USERNAME() or ISMEMBEROF().

Compare RLS approaches

0/8

Comparing data-source-level RLS using calculated field filters against database-level RLS using views or row security policies.

Learn this concept
Unseen

Comparing virtual connection data policies against Tableau data-source-level RLS for centralized security enforcement.

Learn this concept
Unseen

Comparing manually configured user-filter RLS in Tableau Desktop against dynamic, entitlement-table-driven RLS in terms of scalability.

Learn this concept
Unseen

Evaluating the trade-offs of enforcing RLS through a live connection versus an extract, including when security rules take effect relative to refresh timing.

Learn this concept
Unseen

Comparing centralized RLS enforcement through a shared, governed data source against RLS logic duplicated separately across many individual workbooks.

Learn this concept
Unseen

Recommending an RLS approach for an organization that needs consistent security enforcement across many workbooks built on the same underlying data.

Learn this concept
Unseen

Identifying the security risk of relying solely on a user filter manually set in Tableau Desktop compared with a calculation-based, server-enforced approach.

Learn this concept
Unseen

Comparing the performance implications of database-level RLS, which pushes filtering to the source, against Tableau-side calculated-field RLS, which filters after the full dataset is retrieved.

Learn this concept
Unseen

Recommend an appropriate method to connect to data, such as Web Data Connectors, web extract APIs, custom SQL, or ODBC

0/11

  • Recommending a Web Data Connector when connecting to a proprietary web API for which no native Tableau connector exists.
  • Recommending custom SQL when the data required cannot be modeled directly through table selection, such as a complex source-side join or aggregation.
  • Recommending an ODBC connection for a legacy or niche database platform that lacks a native Tableau connector.
  • Comparing a native connector versus custom SQL for a given database platform, factoring in performance and maintainability.
  • Comparing an ODBC connection versus a native connector for a given database platform, factoring in performance and maintainability.
  • Recommending use of an extract API, such as the Hyper API, to programmatically build or update an extract outside of Tableau Desktop.
  • Evaluating when a Connected App or REST API-based data pipeline is preferable to a manually built Web Data Connector for automating data delivery.
  • Identifying the limitations of the deprecated Web Data Connector framework for new development.
  • Recommending the Connector SDK as an alternative to the deprecated Web Data Connector framework.
  • Recommending a JDBC connection as an alternative to ODBC when a platform's driver ecosystem or deployment environment favors JDBC.
  • Recommending a native Tableau connector by default over custom SQL or a generic ODBC/JDBC connection whenever one exists for the platform, for performance and maintainability reasons.

Create connections by using Tableau Bridge

0/10

  • Identifying when Tableau Bridge is required to connect Tableau Cloud to an on-premises data source.
  • Configuring a Tableau Bridge client and pool to support live connections to on-premises data.
  • Configuring a Tableau Bridge client and pool to support scheduled extract refreshes against on-premises data.
  • Determining high-availability requirements, such as multiple Bridge clients in a pool, for a business-critical on-premises connection.
  • Troubleshooting a Tableau Bridge connection failure caused by a network or firewall restriction.
  • Troubleshooting a Tableau Bridge connection failure caused by a driver mismatch or an offline Bridge agent.
  • Comparing Tableau Bridge-based live connections against Bridge-scheduled extract refreshes and recommending the right approach for a given latency requirement.
  • Configuring Tableau Bridge to support a virtual connection's scheduled refresh against an on-premises source.
  • Determining whether Tableau Bridge supports live query capability for a given on-premises virtual connection.
  • Recommending centralized driver and Bridge client version management practices to prevent compatibility failures across a pool of Bridge agents.

Specify aggregation level and strategy for data sources in Tableau products

0/7

  • Specifying a pre-aggregation strategy in Tableau Prep to reduce the row count of an extract that will be published to Tableau Server.
  • Determining the appropriate aggregation level for a published data source that will be consumed by multiple downstream workbooks with different needs.
  • Recommending when the extract setting to aggregate data for visible dimensions should, and should not, be enabled.
  • Specifying how aggregation strategy differs between a live connection, where aggregation is pushed to the source database, and an extract, where aggregation is performed by Hyper.
  • Determining when a data source should not be pre-aggregated because doing so would break a required lower-grain calculation, such as a distinct count or Level of Detail expression.
  • Recommending an aggregation strategy for a Tableau Cloud-hosted data source that balances refresh performance against dashboard-level detail needs.
  • Identifying where pre-aggregation decisions are made in Tableau Prep within the data pipeline.
  • Recommending a Sankey diagram for visualizing flow or transition between categorical states, such as a customer journey or budget allocation.
  • Recommending a radar chart for comparing multiple metrics across a small number of categories.
  • Identifying the limitations of a radar chart as the number of metrics or categories grows.
  • Recommending small multiples, or a trellis layout, to compare a metric's trend across many categories simultaneously without a single cluttered chart.
  • Explaining what data densification is in Tableau.
  • Identifying when data densification is needed to fill gaps for a continuous chart, such as a trend line over sparse dates.
  • Identifying unwanted data densification, such as a cross-join explosion of marks.
  • Controlling unwanted data densification using domain padding or 'show empty' settings.
  • Recommending against a Sankey or chord diagram in favor of a simpler chart type when the added complexity is not justified by the audience's needs.
  • Recommending a bump chart to visualize how a set of items' ranks change over time.
  • Recommending a waterfall chart to visualize the sequential, cumulative effect of a series of positive and negative changes, such as a profit bridge.
  • Identifying where Level of Detail expressions execute relative to dimension filters, context filters, and table calculation filters in the Tableau order of operations.
  • Explaining why converting a filter to a context filter changes the result of a FIXED Level of Detail calculation.
  • Identifying where table calculations execute relative to row-level and aggregate calculations in the order of operations.
  • Explaining why extract filters, occurring earliest in the order of operations, affect all downstream calculations including FIXED LODs.
  • Explaining why data source filters, occurring early in the order of operations, affect all downstream calculations including FIXED LODs.
  • Explaining why a quick filter placed after a FIXED LOD calculation in the order of operations has no effect on that calculation's result unless it is added to context.
  • Identifying that INCLUDE and EXCLUDE Level of Detail expressions, unlike FIXED expressions, are affected by dimension filters because they compute relative to the view's filtered context.
  • Identifying where a set used as a filter executes in the order of operations relative to standard dimension filters and Level of Detail expressions.
  • Troubleshooting a scenario where a dashboard filter is unexpectedly not affecting the result of a FIXED Level of Detail calculation.
  • Troubleshooting a Top N filter that correctly limits the marks shown in a view but produces incorrect aggregate totals because it is a table calculation filter.
  • Troubleshooting a scenario where adding a filter to context unexpectedly changes a workbook's numbers, and diagnosing why.
  • Troubleshooting incorrect results caused by combining INCLUDE or EXCLUDE Level of Detail expressions with regular dimension filters.
  • Diagnosing why a calculated field nesting an aggregate function inside a table calculation produces an error or unexpected result, tracing the cause to the order of operations.
  • Troubleshooting a scenario where an extract or data source filter silently excludes data that a FIXED Level of Detail calculation needs.
  • Troubleshooting mismatched totals in a blended view caused by the secondary data source's filters being applied at a different stage than the primary source's filters.
  • Implementing a dynamic URL action that passes field values into an external website or application, such as a drill-through URL built from a selected mark.
  • Implementing a parameter action that lets a user click a mark to update a parameter, which in turn drives a calculated field or reference line elsewhere in the dashboard.
  • Implementing a filter action for cross-sheet filtering between dashboard sheets.
  • Determining the effect of the 'Show all values,' 'Keep all values,' and 'Exclude all values' target-filter options on a filter action.
  • Planning a chart-swap or KPI-swap interaction using a parameter action combined with supporting calculated fields.
  • Designing chained dashboard actions, such as a filter action followed by a parameter action.
  • Identifying pitfalls related to dashboard action execution order when chaining dependent actions.
  • Recommending whether a set action, a parameter action, or a filter action best satisfies a specific dashboard interactivity requirement.
  • Implementing a set action that adds or removes marks from a set on click to drive a dynamic comparison-group or what-if analysis.
  • Planning a guided, multi-dashboard navigation experience using navigate actions or story points rather than relying on browser back/forward behavior.
  • Identifying high-cardinality joins as a query pattern that generates resource-intensive queries.
  • Using the Performance Recorder or server query logs to pinpoint a specific slow-running query within a workbook.
  • Resolving a resource-intensive query caused by an inefficient custom SQL statement by optimizing the statement or replacing it with native table connections.
  • Identifying when a live-connection query is resource-intensive due to missing database indexing, and recommending an index or a move to an extract as the resolution.
  • Resolving resource-intensive queries caused by unnecessary context filters that force large temporary tables to be recalculated.
  • Identifying that data blending issues repeated secondary-source queries per mark, and resolving the resulting performance cost by moving to a relationship or join instead.
  • Configuring server-level cache refresh settings to maximize cache hits for frequently viewed dashboards.
  • Identifying user-filter-driven views that defeat Tableau Server caching and recommending alternatives.
  • Recommending a schedule of extract refreshes and subscriptions to pre-warm the cache for high-traffic dashboards.
  • Balancing data freshness requirements against caching aggressiveness when configuring server cache settings for a given site.
  • Identifying that row-level CONTAINS or similar string comparison calculations are computationally expensive at scale.
  • Resolving a performance issue caused by a deeply nested IF/ELSEIF chain by restructuring it as a CASE statement.
  • Resolving a performance issue caused by using a Level of Detail expression inside a filter, which forces a sub-query, by replacing it with an alternative filtering technique.
  • Recommending that a row-level calculated field performing string comparisons be converted to a precomputed boolean or integer flag upstream to reduce Tableau-side cost.
  • Using the Performance Recorder's calculation events to diagnose which specific calculated field is the primary cause of slow workbook rendering.
  • Recommending that a calculation reused identically across many workbooks be materialized in a database view or Tableau Prep flow rather than recreated per workbook.
  • Interpreting a performance recording's Gantt-style timeline to identify which events, such as queries, calculations, or layout rendering, consume the most time.
  • Distinguishing an 'Executing Query' bottleneck from a 'Computing Layout' or 'Geocoding' bottleneck in a performance recording.
  • Identifying the differing remediation for query bottlenecks versus layout or geocoding bottlenecks in a performance recording.
  • Using a performance recording to identify a specific dashboard filter or extension causing a slow load, and determining a fix.
  • Reading query text captured in a performance recording to identify an inefficient join or a missing predicate pushdown.
  • Using a performance recording to compare load performance before and after implementing an optimization, such as adding a context filter or changing the connection type.
  • Recommending the workflow for capturing a performance recording to investigate a dashboard that intermittently loads slowly.
  • Correlating a Desktop performance recording with Tableau Server backgrounder or VizQL server logs when a workbook performs well in Desktop but slowly once published.
  • Identifying that a dashboard with an excessive number of sheets causes slow rendering.
  • Identifying that a dashboard with an excessive number of dashboard objects causes slow rendering.
  • Resolving a performance issue caused by too many quick filters, especially 'Only Relevant Values' filters that trigger repeated domain queries.
  • Recommending a reduction in the number of marks rendered on a single view, through aggregation or filtering, to improve rendering performance.
  • Identifying when floating objects and complex container layouts are slowing dashboard render time, and recommending layout simplification.
  • Recommending disabling unnecessary tooltips, animations, or auto-updating features that add rendering overhead to a heavy dashboard.
  • Implementing an aggregated calculation that must respect a specific dimension's granularity, such as computing the average of a per-customer sales sum.
  • Using ATTR() to safely include a dimension in a calculated field without introducing an asterisk indicating mixed underlying values.
  • Implementing a calculation that aggregates a measure at one dimension's grain and then re-aggregates the result across a different dimension.
  • Troubleshooting a 'cannot mix aggregate and non-aggregate arguments' error that occurs when trying to include a dimension directly inside an aggregate calculation.
  • Implementing a WINDOW_SUM or WINDOW_AVG calculation with a custom addressing and partitioning configuration to compute a moving total across a specific dimension.
  • Implementing a nested table calculation, where one table calculation is applied to the result of another, such as ranking a running total.
  • Implementing a multi-directional table calculation using 'down then across' addressing across two dimensions and interpreting its result.
  • Troubleshooting incorrect table calculation results caused by an incorrectly chosen addressing or partitioning field.
  • Implementing a table calculation that resets at a specific dimension boundary, such as a running total that restarts each year.
  • Recommending whether a table calculation or a Level of Detail expression is the more appropriate approach for a computation that could be solved with either.
  • Implementing an advanced table calculation to compute a percent-of-previous or index-based comparison across a custom, non-alphabetical sort order.
  • Using 'Hide' rather than 'Exclude' to remove a mark from a table calculation's display without disturbing the addressing and partitioning context the calculation depends on.
  • Configuring a custom fiscal year start date at the data source level and identifying its effect on default date hierarchies and calculations.
  • Implementing DATEPART or DATENAME with the fiscal argument to build a calculation aligned to a non-calendar fiscal year.
  • Implementing a calculation to compare a metric against the same period in the prior fiscal year when the fiscal year start differs from the calendar year.
  • Implementing a custom calculation to align dates to an ISO 8601 week-numbering standard or a non-default week-start day, distinct from a fiscal year setting.
  • Implementing a nested Level of Detail expression, where one LOD calculation references another, to answer a multi-level aggregation question.
  • Implementing an EXCLUDE Level of Detail expression nested inside a FIXED expression to compare two different levels of detail simultaneously.
  • Implementing a nested Level of Detail expression to solve a cohort-style analysis, such as identifying customers who purchased in both period A and period B.
  • Recommending a nested Level of Detail expression over a self-join or data blend to answer a cross-grain analytical question.
  • Combining a nested Level of Detail expression with a table calculation to rank or band the inner expression's result.
  • Implementing a solution that combines a FIXED Level of Detail expression with a table calculation, such as ranking customers by their fixed lifetime value.
  • Implementing a combined fiscal-date and Level of Detail calculation to compute a fiscal-year-aware cohort metric.
  • Combining a set, a Level of Detail expression, and a table calculation to build a dynamic top-N-versus-rest comparison view.
  • Troubleshooting a complex calculation chain combining a Level of Detail expression, a table calculation, and a parameter, where an intermediate step produces an unexpected null.
  • Troubleshooting a 'cannot blend on this field' or ambiguous Level of Detail error arising from mismatched dimensions between a primary and secondary data source.
  • Troubleshooting a table calculation that produces different results depending on which fields are present in the view, a hidden-dependency issue.
  • Diagnosing incorrect advanced calculation results caused by data type mismatches, such as comparing a string to a number.
  • Diagnosing incorrect advanced calculation results caused by locale-specific date parsing.
  • Troubleshooting an unexpected result caused by Tableau's automatic aggregation of a calculated field that implicitly mixes row-level and aggregate logic.
  • Mapping a requirement for a single source of truth for KPIs to Tableau's certified data source and data source project structure capabilities.
  • Mapping a regulatory data-residency requirement to a Tableau Server on-premises or region-specific Tableau Cloud pod deployment decision.
  • Mapping a requirement for auditable access history to Tableau's Admin Insights and repository-based activity logging capabilities.
  • Mapping a requirement to prevent uncontrolled proliferation of duplicate data sources to Tableau's certification and data source project governance features.
  • Mapping a requirement for role-based content management to Tableau site roles and permission templates.
  • Mapping a requirement for role-based content management to Tableau project hierarchy locking.
  • Mapping a requirement for dev/test/prod lifecycle governance to Tableau's content migration and promotion capabilities.
  • Mapping a requirement for content approval before production release to a staged project structure with locked permissions and a controlled promotion process.
  • Mapping a requirement for centralized business-glossary and metadata management to Tableau Catalog's external asset and custom metadata capabilities.
  • Recommending a project hierarchy strategy for securing content across a multi-department Tableau site.
  • Recommending locked versus customized permissions within a multi-department project hierarchy.
  • Recommending group-based permission assignment over individual user-level permissions for scalability and maintainability.
  • Recommending how site roles and workbook permissions restrict access to sensitive published content.
  • Recommending how row-level security restricts access to sensitive data within published workbooks and data sources.
  • Recommending a permission configuration for a scenario requiring some users to view but not download or export a workbook's underlying data.
  • Recommending a strategy for securing embedded or externally shared content, such as through trusted tickets or connected apps, as distinct from standard internal access.
  • Evaluating the security implications of publishing a workbook with 'show sheets as tabs' enabled by default.
  • Evaluating the security implications of publishing a workbook with download permissions enabled by default.
  • Recommending a strong site authentication configuration, such as SSO with multi-factor authentication, as the foundation of a comprehensive content-access security strategy.
  • Recommending a data source certification process to designate an authoritative, trusted data source for an organization.
  • Recommending governance practices, such as project structure and certified sources, to minimize the proliferation of duplicate data sources.
  • Configuring a Warning or Deprecated data quality warning on a published data source for a given scenario.
  • Configuring a Stale Data or Under Maintenance data quality warning on a published data source for a given scenario.
  • Recommending a review and ownership process to keep certified data sources accurate and prevent low-quality sources from being certified.
  • Recommending a strategy to communicate a newly discovered data quality issue to consumers of a published data source in near real time.
  • Recommending a strategy for deprecating and eventually retiring an outdated data source while minimizing disruption to dependent workbooks.
  • Recommending automated, scheduled data-validation checks that proactively flag emerging quality issues before they require a manual data quality warning.
  • Specifying that identifying the most resource-intensive workbooks or users on a site requires an administrative view such as 'Stats for Load Times' or Admin Insights, rather than a single workbook's performance recording.
  • Specifying that diagnosing a site-wide slowdown, as opposed to a single workbook's issue, requires background job and task administrative views.
  • Specifying that auditing who has accessed or modified a sensitive workbook requires administrative activity views rather than workbook-level permissions alone.
  • Specifying that identifying stale or unused content for cleanup requires administrative views showing last-accessed date and view-count data.
  • Specifying that identifying broken or orphaned data source connections across an entire site requires an administrative content view rather than manual workbook-by-workbook review.
  • Recommending the Tableau Server repository or Admin Insights published data sources as the basis for a custom, cross-site usage-tracking dashboard.
  • Recommending the 'Stats for Space Usage' administrative view to identify which projects or workbooks consume the most storage.
  • Recommending the 'Stats for Load Times' administrative view to identify slow-loading content across a site.
  • Recommending the Admin Insights Performance data source to identify slow-loading content across a site.
  • Recommending the 'Background Tasks for Extracts' administrative view to diagnose failing or overdue scheduled extract refreshes.
  • Recommending the Admin Insights License data source to build a report tracking Creator, Explorer, and Viewer license consumption trends over time.
  • Recommending the Tableau Server repository or Admin Insights for long-term historical trend analysis of site usage.
  • Recommending server logs or live administrative views for real-time troubleshooting of site issues.
  • Recommending the Tableau Metadata API or Tableau Catalog, rather than manual admin views, for programmatically auditing lineage and content relationships at scale.
  • Mapping a requirement to publish a workbook with refreshable, up-to-date data to the appropriate connection type and scheduled task configuration.
  • Mapping a requirement for scheduled, automated distribution of a report to a stakeholder's inbox to Tableau's subscription feature.
  • Mapping a requirement for external, unauthenticated public sharing to Tableau Public or embedded trusted-ticket options.
  • Evaluating the trade-offs of Tableau Public versus embedded trusted-ticket sharing for external audiences.
  • Mapping a requirement that users be notified only when a metric crosses a threshold to Tableau's data-driven alerts feature.
  • Mapping a requirement to prevent a workbook's underlying data from being downloaded or exported to the appropriate publishing-time permission configuration.
  • Mapping a requirement to embed a live, interactive dashboard inside a third-party web application to Tableau's Embedding API and Connected Apps capability.
  • Recommending a dev/test/prod project structure and content promotion process for the workbook lifecycle.
  • Recommending packaged workbook archiving as a backup practice in workbook lifecycle management.
  • Recommending a maintenance cadence for reviewing and updating published workbooks after events such as a source schema change or a fiscal year change.
  • Recommending an approach for retiring and archiving workbooks that are no longer actively used, including stakeholder communication.
  • Recommending data source filters to distribute one workbook across audiences with slightly different data needs.
  • Recommending REST API or Content Migration Tool-driven automation for the deployment stage of the workbook lifecycle to reduce manual promotion errors.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Tableau Consultant studiers. 595 members and growing.

Go to Discord

Comparing centralized RLS enforcement through a shared, governed data source against RLS logic duplicated separately across many individual workbooks.

Explainer

Learn More

Practice Question

Keep going

Next conceptRecommending an RLS approach for an organization that needs consistent security enforcement across many workbooks built on the same underlying data.

Checklist progress

0/281 (0%)

0 of 281 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Tableau Consultant studiers. 595 members and growing.

Go to Discord

Explainer

Row-level security (RLS) controls which data rows users can see based on their identity or role. Organizations can enforce RLS either by applying filtering rules individually to each workbook or by centralizing those rules at the shared data connection level. The centralized approach reduces maintenance and security risks, while the decentralized approach requires manual updates across every asset.

Core information
  • Centralized RLS uses virtual connections with data policies to enforce filtering at the connection level rather than the workbook level.
More details and nuances
  • Centralized data policies are enforced server-side on every query, eliminating the risk that an author forgets to restrict save or download permissions on a workbook.