Why Writing to a Separate Dataset?

Owned by Ricardo Pires
Last updated: Mar 01, 2024 by Bruno Gomes
2 min read

Applies to Write-Back Server and Write-Back Cloud

Question

I want to overlap existing data, why does Write-Back use its own dataset?

Some of the use cases for Write-Back are about fixing data and so the main questions is why can't Write-Back immediately update existing tables.

Answer

Write-Back goal is to enable any user to submit data directly on a dashboard, this means we have to make some compromises to ensure its correct usage. Imagine someone would configure Write-Back to update the ERP changing invoice values. By writing to a separate dataset and with the audit mechanism we are sure about that, even though we are giving freedom for the Creators and Explorers to be creative and use Write-Back in different ways, the original data is never touched and we can always keep track of who did what.

This detailed tracking can be very important in different reasons:

  • Along time users might introduce inaccurate inputs, and you want to know what was the original submission

  • Any possible mistakes that might arise can always be fixed, no data is overlapped

  • To ensure compliance, you know who did what 

That is why a separate dataset is the best choice, since the extension is fully managing it Write-Back can ensure all the premises above despite of user actions.

However, this doesn't mean you cannot choose to blend these inputs with existing data by leveraging different mechanisms:

  • Tableau

    • Data source joins using Tableau relationships allow combining data from different tables and thus connect the dataset with exiting data. This should be the preferred method for joining information. 

    • Data blending can be used to associate the Write-Back dataset entries with existing data, the fields chosen from the source sheet can be used as linking fields. For more information check the Tableau documentation. This method should be used if your original data requires an extract and you want to have a live connection to Write-Back data. 

These methods are more complex so you should only use them if your use case cannot be achieved with Tableau directly:

  • Database

    • Create a database view that overlaps existing data with manual data, analytical functions can be used to give preference to manual data.

    • Use database triggers that based on the Write-Back dataset update or insert data on other table. *

  • Bring or send data from Write-Back

    • On your organisation an ETL tool might be used for other purposes or even through database triggers and be re-used here with Write-Back.

    • You can follow a strategy where manual data inserted on Write-back is then used to update or insert data on original tables. *

    • Another option is either on an initial run or periodically bring the original data by doing inserts on Write-Back tables which will than allow users to provide the manual inputs. On this approach Write-Back will become your new main table for the business process. For more information check the Back-end Procedures - Write-Back Server page.

* Please be aware that these two mechanisms can overlap existing data that might not be recoverable without restoring a database backup, use them wisely implementing any particular validations required to ensure no data is lost inadvertently. 

Updating Existing Data     Tableau: Blend your Data   Tableau: Use Relationships