I’m trying out the input columns and have a use case where I want to have the input column within a pivot.
So for example I have month pivoted across the top and I have the dimension attributes on the left. Within each month I have days and rate and a forecast amount (days * rate). I wanted to add a days override input column that I can tie into a revised forecast column (override days * rate) which I have and works if the data is unpivoted, but as soon as I pivot the year month, the override days sits outside of the pivoted data.
Is this functionality with input columns supported or only in an unpivoted view?
E.g.
Override works unpivoted, but not really useful in a long list:
When pivoted on month, you can see the override sits outside of the pivot and the rows then get split because the override has been entered at the month level
Hi Jo!
Is the issue you’re facing that the input column is not ordered where you’re expecting it, or that the function of the input column is broken when pivoted?
Hi James, I think probably a mixture of both if my expectation is right. I have assumed that if it’s a measure then when I create a pivot, the input column should be in each year month so I could have a value per month, which I can if it’s in a normal table view. As soon as I pivot it, the input column sits outside of the pivot and only exists once, so I can’t add override values to each month on a row
I see, thanks. Input columns function as dimensions not measures and would be placed outside of pivots like you’re seeing in that query.
If each client you have has a unique override_days per month, the unpivoted table would be the best option.
You could create a calculated field that carries the value of the input column within the pivot i.e. with =C1as the calculation, but not a new input column per pivot column.
Thanks James, that’s good to know. I think because it asks you whether the column is text or numeric, I assumed if I chose numeric it would be a measure and behave in that way, and not a dimension. This option won’t work for our use case so it’s not something we’d be able to use for the scenario I had in mind. Thanks for clarifying.
