With the ability/normal experience of creating many DAX measures in Power Pivot, the Values area of the PivotTable design is now too small to use effectively. Since the Values area only shows about 4 rows it's really difficult to organize fields correctly when try to drag fields around if you've got 10 or more fields in your Values area. (not at all uncommon for Power Pivot users, although certainly not restricted to them.)

With the introduction of slicers, however, we also tend to use the Report Filter area less, and don't usually add as many fields to the row/column areas.

My suggestion is to allow collapsing the individual field areas in the "Field and Area side by side view". This would allow much more space to be assigned to the needed area(s) in order to allow for an easier PivotTable design/maintenance experience.

I have a full write up of the suggested change on my blog at http://www.excelguru.ca/blog/2015/11/02/suggestion-to-improve-the-pivot-table-experience/ including screen mockups.

Enable writing measures in DAX in a pivot table connected to Tabular or Power Pivot.
In practice, it would be enough to enable a choice between MDX and DAX in the "New Calculated Measure" dialog box and use the following syntax for creating a DAX measure instead of an MDX member in measures…

CREATE SESSION MEASURE [Model].Sales[My Sales 2] = SUMX ( Sales, Sales[Quantity] * Sales[Unit Price] /5 )

I received this requests from several enterprise customers, but I think it's useful to any data analyst accessing tabular models (but you should be able to write DAX measures also for SSAS Multidimensional, why not?)

PivotTables and data entry butt heads with each other.

Data is easiest to enter in a crosstab format (headings on rows and columns). The row and column headings eliminate having to specify them for each value.

For example, a fuel price table:

.........Canada..................................USA....................................
.........Diesel...Gasoline...Propane...Diesel...Gasoline...Propane
2012
2013
2014

If I want to specify $50 as the Canadian diesel price for 2013, I enter "$50" at the intersection of the correct headings.

However, to be able to use PivotTables, the data must be moved to "record" format (no row headings, only column (field) headings, and a lot of repeated information). This is usually stored in an Excel table.

For example:

Year...Fuel....Country...Price
````````````````````````````````````
2012..Diesel..Canada...$70
2012..Diesel..USA.........$60
...
and so on.

Now if I want to enter the same information as the crosstab example, I have to enter "2013", "Canada", "Diesel", "$50". The other problem is that there is no way to enforce uniqueness among the year-fuel-country combinations (compound primary key). For example, for 2013-Canada-Diesel, I could have 2 records, one for $50 and another for $40. I cannot prevent duplicate entries; I can only point them out if they occur using COUNTIFS. In SQL, you have the choice to enforce uniqueness.

We need some sort of PivotTable-able data entry crosstabs for the best of both worlds.

I suggest the following. The user can link a data entry crosstab to a table or vice versa. When that happens, the table autopopulates with all combinations of the crosstab's row and column headings, and the value to be entered is blank by default. When the user updates the crosstab, the table updates and vice versa.

Note that the data entry crosstab is like a PivotTable, but with some small differences. PivotTables are meant for summarizing, so you use an aggregate function (e.g. sum, average, max). A data entry crosstab would be meant for data entry and so requires that all fields that uniquely identify the table values to be present (these identifying fields are called a compound primary key in database terms). Both can rearrange the positions of headings freely.

Also note that crosstab data entry would also be useful in Microsoft Access. The closest that I've seen anywhere is LibreOffice Base letting you edit data through query results if no aggregate function is used. In summary, if a crosstab has the primary key entirely present by combining row and column headings, then it can and should be used for data entry and can and should be PivotTable-able.

(I realize that a PivotTable can be used to show raw values in a crosstab format by ensuring that all identifying fields of the value are present in the table. That way, the aggregate function works on only 1 value, and so returns that value. However, you cannot enter data in PivotTables.)

Ask any banker, consultant, accountant, project manager, anyone preparing a business plan. They will have two files. A workbook when they run their calcs. And a PowerPoint deck where they will present their analysis. And they will frequently correct or refresh the analysis and then update the PowerPoint deck.

Right now the only thing that remotely looks like a way to link the two is pasting tables as link in PowerPoint. However it is slow, unstable, and have an inconsistent format. And if you want to link a number in the middle of a sentence in a textbox, no luck.

Instead of creating yet another way to do a Pivot Table, it would VERY useful to spend some time solving this problem. Whether it is by saving data in an intermediary file, or giving us a mark up language in parallel to the WYSIWYG UI (think WPF editor in Visual Studio). But this is a real pain point on your users.

Please Microsoft, focus on your users. PowerPivot is for IT professionals. They get paid to deal with this shit, they don't really need you. Not your users.

Allow the user to configure if the slicer is always in view or pops up on-demand. Activation/visibility could be triggered by selecting a visible report filter field or pivot table column header. Alternately, a report filter field could be configured to pop-up a slicer instead of, or in addition to the normal selection box. Another alternate would be to have report filter field style boxes independent of the pivot table range which would pop-up the slicer when selected. Lastly, a slicer selection panel could be added with a list of parameters to choose which would cause the slicer to pop-up

The core benefit of this function would be to reduce the amount of physical space occupied by static slicers on a crowded pivot table page. Slicers are superior to report filter boxes since the indicate which field parameters are not available due to other filtering actions on the same pivot.

A VBA-enabled file is provided as an example, which is also published at www.contextures.com