Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Write-Back Server
    • Tableau extensions are web based and deployed on a separate application server from the Tableau Server. This means that Write-Back should be placed side by side with your Tableau Server, ideally on a separate machine. Users will interact with the Write-Back server either on the Tableau Desktop or on Tableau Server, the behavior is very similar as even on the Tableau Desktop extensions are executed on an embedded browser.
    • The Write-Back server location is defined on the Tableau dashboard by adding a trex file. This is the file that tells Tableau where is the Write-Back server, since Write-Back runs on your environment you should always select my extensions and locate the file that is provided after finishing the installation process. Bear in mind that all Creators that will build dashboard with Write-Back need to have the corresponding trex file in hand.
  • Write-Back dataset Tables
    • Write-Back acts as SQL engine storing the data submitted by users on tables. Whenever a Creator makes a new configuration on Write-Back a table is provisioned on the Write-Back database. Since a table is created for each dataset it is advisable to have Write-Back configured to use a separate schema on your database. This way Write-Back environment is more contained avoiding issues and you always know for sure that every table has the same origin. In order to achieve this, a database user with full permissions on the schema is configured on the Write-Back back-end. You should also have a read-only database user that can be leveraged by Tableau Creators to build dashboards with data sources pointing at Write-Back data. Write-Back table structure only changes if the configuration is changed so bearing this in mind you can leverage this fact by following our Back-end Manual Data Procedures and apply ETL, store procedures or any other mechanism on top of the Write-Back tables.
    • By writing to a separate dataset and with the audit mechanism we are sure 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 audit trace 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
  • Data Warehouse
    • Your existing data will reside on a separate schema or even a separate database and thus you will need to blend it with Write-Back data by leveraging different mechanisms:
      • Tableau
        • 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. While being easy to use this can have an impact on performance as the joins are done in memory on Tableau. 
        • Relationships and Data source joins allow combining data from different tables that might even be on different databases and thus connect the dataset with exiting data. For more information check the Tableau documentation. If you have all data on the same database this option is easy to apply and performance should not be affected, Tableau will push the joins to the database. 
      • Database
        • Create database views.Your existing data will reside on a separate schema or even a separate database and thus you will need to blend it with Write-Back data by leveraging different mechanisms:
  • Back-end data processes
    • While Write-Back does not provide OOTB any backend processes it is possible for technical users to implement them. These processes can be responsible for automatic tasks such as:
      • Pre-populating datasets, for instace with a basis for forecasting
      • Cleaning, old data or not relevant anymore
      • Syncronizing with other databases, for instance with an analytical database 
    • These can be implemented in different ways using:
      • Database
        • Use database triggers that based on the Write-Back dataset update or insert data on other table. 
        • Using stored procedures
      • Extract Transform and Load (ETL)
        • On your organization an ETL tool might be used for other purposes and be re-used here to update or insert data on other tables. 
    • Please be aware that these mechanisms can overlap existing data that might not be recoverable without restoring a data base backup, use them wisely implementing any particular validations required to ensure no data is lost inadvertently. There will be a delay on making the data available but these techniques can improve performance while the data is being read on the dashboards.  Fore more technical details please check the section BacBack-end Data Processes.

  • Security
    • Since Write-Back runs on a separate server we need to ensure that security is also applied here. Write-Back supports multiple authentication mechanisms including single sign-on technologies allowing to match the security on the Tableau Server and simplify maintenance always keeping users synchronized. 
    • For authorization you should resort to Tableau Server security ensuring that dashboards with Write-Back configured are only accessible by users that are entitled to submit information.