How to Send Each Customer or Location the Right Tableau Report

Each customer needs a report generated for its own data, as well as an email sent to its own address. Advanced Tableau Report Scheduler (ATRS) can repeat that work using a maintained list that pairs the customer’s report values with the approved destination.

Imagine a facilities company sending weekly service summaries. Northside Estates wants to know which visits were completed at North Gate and Riverside, and which actions remain open. Harbour Offices needs the same kind of summary for Harbour House. They share a Tableau workbook, but they should never receive the same all-customer attachment.

An email headed “Northside Estates” would not solve the problem if its PDF still contained Harbour’s visits. The customer selection has to reach the report before the file is generated. The address then determines where that particular file goes.

Tableau’s own PDF subscriptions and user filters may already meet a requirement for personalized snapshots sent to permitted Tableau users. The example here uses a separate ATRS export workflow: one configured Tableau account produces customer-specific files from maintained reporting instructions. The customer’s email address is not a Tableau sign-in and does not automatically limit the exported data.

We’ll follow Northside’s weekly summary from its customer record to the received PDF. Harbour’s contrasting report gives us a practical way to see whether the customer selection actually changes.

The facilities company already knows which sites belong to each customer and which contact should receive the service summary. Those relationships become the starting point for automation. ATRS calls the database query or table supplying these instructions a data driver.

For Northside, an illustrative record contains customer ID C104, the name Northside Estates, its approved mailbox and the completed service week. A separate delivery key, such as SV-1042, helps the reporting team identify that particular instruction. These are example business fields, not a required ATRS database schema.

The distinction between ID and name matters when a customer changes its trading name. Northside’s greeting and filename can change while C104 still selects the same approved sites. A display name alone is a less dependable way to identify the records the report should contain.

The list also needs to represent the way people receive reports. Two contacts sharing one customer summary is different from one account manager receiving summaries for several customers. Repeated rows can otherwise produce duplicate files or unexpected attachments. Decide that relationship before mapping the fields.

An account-team contact should own approved recipient changes, while the reporting owner maintains the query. Previewing the resulting records lets both people spot an inactive customer, a missing ID or an old address before those instructions become real deliveries. The database can supply the values; the business still decides who is entitled to receive them.

With the driver ready, create an ATRS Data-Driven Schedule and connect it to that query. Select the Tableau account and report item, then map the customer ID to the report input that selects customer data. Map the recipient field to the destination. For the first review, send the results to internal test addresses.

Northside’s C104 value should make the workbook return North Gate and Riverside. That relationship must exist in the Tableau design; entering a value in a schedule cannot create a missing customer filter. The workbook author can explain whether the input is a parameter, a filter or part of another selection rule.

The configured Tableau account supplies the access used for the export. If the workbook contains user-dependent calculations, inspect their behavior under that account. ATRS does not become the customer merely because its destination contains the customer’s mailbox.

Once the first PDF contains the correct sites, use the maintained name and week in the subject and filename. “Northside Estates — weekly service summary” gives the recipient useful context, and the period inside the PDF keeps that context when it is forwarded.

ATRS can also group reports by email address. That may suit an account manager covering several customers, but it changes how files are collected into messages. Choose it for a specific receiving need, then inspect the resulting attachments rather than assuming the grouping also changes their data.

Open the two internally delivered samples side by side. Northside’s PDF should contain North Gate and Riverside, while Harbour’s should contain Harbour House. If both files show all three sites, the mailing step may be correct but the customer selection is not.

Then read Northside’s email as its contact would. The subject, reporting week and PDF title should describe the same summary. The account manager’s copy should contain the same Northside information, rather than a broader report accidentally attached to a similar message.

A customer with no activity is a useful next example. Perhaps the contract still requires a weekly “no visits” summary; perhaps the business deliberately suppresses that output. Either can be appropriate, but it must be distinguishable from an unknown customer ID. Test a controlled invalid value internally and inspect the actual workbook and schedule behavior. It should not quietly become an approved all-customer delivery.

Exception handling needs the same business context. These customer summaries may be independent, allowing unaffected deliveries to continue while one is investigated. A different reporting commitment might require the batch to remain together. Configure and test the choice before a customer depends on it.

Retain the two contrasting PDFs and the driver records that produced them. They explain correct selection more clearly than a message saying the schedule completed, and provide something concrete to compare after a workbook change.

A few weeks later, Northside appoints a new service contact. The account team approves the mailbox change, while C104 and its sites remain the same. Updating that maintained destination should change who receives the summary without changing what Northside’s report contains.

A site transfer is different. If Riverside moves to another customer, the underlying customer relationship and report selection need attention. Repeating the Northside/Harbour comparison after that change shows whether the next weekly files reflect the new arrangement.

The driver population is worth watching too. If a list normally returning fifty active customers suddenly returns five, the absence of export errors would not make the missing forty-five deliveries correct. Compare the selected customers with the business’s expected audience before an important cycle.

When Northside requests a replacement, establish whether it needs the original week’s saved output or a new report reflecting corrected records. Check what was already sent and focus recovery on the affected delivery. That keeps an individual correction from becoming another full round of customer emails.

For the recipient, the benefit is a recognizable weekly summary of its own sites and outstanding actions. To explore that relationship with your own customers, evaluate Tableau report bursting with ATRS using two contrasting customers and the files each should actually receive.