@Stephen Atwell - I like the direction you're headed with these data tables for gathering data from non-TBMA End Users.

Do you have a timeline on when this feature will be available? (i.e. giving End Users the ability to enter data in custom report in PRD without triggering calculations in the back end) This is something that our organization really needs at the moment.

Jim,

Editable tables from the reporting surface will not version over time. Historically this has caused a large number of unhappy customers when users accidentally version the table. Instead an editable table has 1 editable version, that can be edited on the reporting surface, and spans all of time. When uploading it into the table transform layer the TBMA can specify what time period they wish to upload to. Thus if they want to version the table annually, they maintain/edit 1 version, and upload it to the desired timeperiod. Some of our customers also have a column such as 'year' that they put into an editable table, and filter the editable table by on the reports. This will be possible, and then after feeding such an editable table into the transform layer a date partition step can be used to send the rows to the correct time period.

Hi Stephen,

Thanks for the insight into how editable tables have been designed to work now, and in the future, for R12.

One question I have is around the use of editable tables via the reporting surface:

It used to be possible in R11 to lock the editable table in a report to a specific time period - usually "Start of current fiscal year" - so that users could enter data relevant to the year of the Apptio time period selected. This allowed yearly versions of the editable table to be maintained easily over time. (The classic use case for editable tables is something like a Cost Centre to ITRT mapping - which you may be updating in the current year for actuals as they arrive each month, but also maintaining next year's version for the budget model...).

Is it going to be possible to edit and "version" data over time within editable tables when they are available via the report surface?

Many thanks,

Jim 

OK! NOW it makes total sense! I can certainly appreciate having the two compartments if the goal is to address non-TBMA user inputs. The original post was missing the use case for doing it the new way. Now having the input it really helps to process the intent. Good job!

Richard, I cannot answer your question without making some forward looking statements, so all the usual caveats on the following being subject to change without notice applies.

This is the first step of Apptio's editable tables roadmap. Many of our customers want non-TBMAs to be able to enter data into an editable table without leaving the production environment, and without entering studio mode.  The current state of the editable tables backend does support this.  So much of what I'm describing you cannot do through the UI at the moment, but parts of it are in place.

The intention here is that when we get editable tables onto the reporting surface, multiple users can edit them directly from production. We also want to support simple ad-hoc query reports against the editable data, and have them update in real-time. When you update an editable table, it spans all environments. Similarly, the data in an editable table does not actually get tracked via check-in/checkout anymore, and thus data changes don't trigger a calculation. The split is because of this 'multiple users changing data in production without causing calculation' plan for the future. 

So the answer really is that the 2 documents have a different currency of data. Changes under 'editable tables' are real-time and span environments, changes under 'tables' section follow a calculation. The intent is that you can feed your editable table data into the calculation layer (Tables) for queries that cannot be done in real-time.  This distinct project grouping will allow the TBMA to author reports that leverage editable tables while knowing what will, and what won't update in real-time for their data entry users.

Hope that helps. I know it's a lot of future looking statements beyond what is there today. But the reason why editable tables is now split out is that it is a stepping stone to a much larger editable table feature that can be used outside of studio mode.

@Stephen Atwell this seems like a really cool new feature. Is there a reason why the editable table exists in both the Tables compartment and Editable Tables compartment? Quite honestly feels like having to update the table in editable tables and then in the tables compartment are unnecessary steps.  

Time versioning editable tables!!!!

SHUT THE FRONT DOOR!!!! 

@Stephen Atwell hi5