Reference current table in template start expression

I am wondering if it is possible to reference the current table in a template start expression. I am trying to develop a monthly report that would email a .pdf to specific users for each of 19 different tables. The report would look the same for each table containing the same columns and column names but different data for each column. I see that you can use the <<_TABLENAME>> variable in the template to reference the current table but I cannot seem to find a way to reference it in the start expression. It would be nice to be able to point each process to the same template and reference the context of the table to process is running on. This is the start expression I have tried <<Start: ORDERBY(Filter(CONTEXT(โ€œTableโ€), ([Grandfathered] = TRUE)), [LastName], False)>> which did not work. Note: When I replace CONTEXT("Table") with the string for a table name the expression does work. I think the problem is that the tablename used by FILTER() can't be an expression, so the question is if there is another way to work around that?

0 1 300
1 REPLY 1

I don't think there is a way to dynamically reference the table name in the way you wish.

Also note, you must be running the Scheduled Bot with "ForEachRowInTable" is off.  I don't believe there is a Table reference provided to the template.  The bot acts as a switch to run/not run the template based on table criteria but no data is sent to the template.

Thirdly, I don't think CONTEXT("Table") works in a template.  From my understanding, this function gets the Table associated with the current view.  Since the template is processed on the server, there is no view context from which to retrieve the Table.  I have not used this version of the function so I am going by the documentation.

Lastly, if all 19 tables have such a similar structure that they can be used by the same template, then I would consider combining them into a single table BUT adding a column used to identify the different sets of rows. You can use Slices to keep them separated within the app.

But then you CAN build the report automation in such a way that a single template can be used.  It would require the introduction of some lightweight sort of Monthly report table used by the Bot to specify which set of rows you wish presented on the template.  This row is passed to the template providing the necessary parameters to the template expression to select its rows of data from your single data table.

The positives to combining the tables is there is much less table overhead and maintenance.  You only need the table columns specified once so smaller footprint.  If there needs to be a table change you won't have to make it in 19 different tables.  Additionally, there often is a need at some point to combine the data from the segregated tables.  Depending on the needs, it can become very difficult to combine the info when in different tables.

The negatives of combining tables is the increased size of the single table.  Performance starts to become a concern but there are mechanisms to deal with this if needed.  

In my opinion the positives outweigh the negatives.

Top Labels in this Space