Desired functionality:

• Open a blank document in MS Word.


• Save it as "MyTempReport.docx"


• MS Word menu > Insert [tab] > Text [group] > Quick Parts > Field ...


• From "Field Names" choose "FileName".


• In the Field Options area there should be an additional checkbox described as something like File basename only (without ".docx" file extension ).


• With the option selected the resulting field will be "MyTempReport".

Motivation: In MS Word you sometimes want to insert a FileName field in the header or footer but make it independent of the fact that the document source is a Word document. This is the case when you want to distribute the Word document saved as a PDF. It no longer remains true that folk receiving PDFs from you are receiving a "MyTempReport.docx".

Currently, the default "Save" syncs the file to Sharepoint / OneDrive, then syncs from the cloud back to the local drive. This is a bad sequence, as, if there is a problem uploading and the file cannot be synced, the file is then completely lost. This feature can be manually overridden by going to "File," "Save As," and selecting "This PC," but must be done every time. Besides risking loss of data, by syncing to Sharepoint/OneDrive first, it locks up the file from being able to be used. If the file were simply saved locally first (which is fast), the document could be released for editing while the local file syncs to the cloud, which is exactly how Dropbox works.

Please consider this as part of the "Options" for the sequence for saving files, i.e., "Save to local drive first, then sync to cloud," or "Save to cloud first, then sync to local drive."

Thanks for listening. I'm working on a critical document and cannot afford for versions to be lost because of a bad cloud sync.

when sharing links to documents, etc, the URL's are way too long.

Can you integrate something like bitly or another tool to make them less than the 208 characters that the last link I shared was.

The ideal place to offer this feature is when you are given the option to 'copy' the URL.

I am also waiting to see a response from this post: https://goo.gl/h6wTRt

The last comment says:
*Update March 15, 2016: We’re working on a new approach to shortening the sharing links that will better enhance our users’ experience. Unfortunately, we had to remove the current experience in preparation for the new one. We always keep the best interest of our users in mind so we appreciate your patience as we work this out. We expect to have it ready soon.

Double-clicking an Internet calendar item (.ics file) attachment in Outlook causes a new calendar to be created, instead of opening it or asking if it should be added to the user's calendar as expected (and as previously implemented in earlier versions of Windows/Outlook).

To add it to the current calendar, it must be saved to the local drive then opened (File>Open). Outlook then asks if it should be opened as a new calendar or added to the current calendar...this same behavior should be used for double-click open.

Dragging the .ics attachment to the calendar results in a transient error message, though the item does seem to be added to the calendar.

Office 365 Groups (aka: "unified-groups") are becoming the "standard" share target in Office 365. You can share SharePoint content (files, list items, etc.) with an O365 Group. You can share Microsoft Stream content with an O365 Group. You can share a Flow with an O365 Group. You CANNOT, however, share a PowerApp with an O365 Group. This is a huge issue and greatly complicates our job of "selling" PowerApps as a solution.

For example, we've successfully convinced a LOT of our client groups that an O365 Group is a better solution than "just" a SharePoint site (most of these had sites/site collections in our SP2010 environment). Many of them latched onto Teams as well, and by an large, they've been off & running. Then, they want to build a PowerApp to make it easier for their people to enter or update data. Sure, they can build the app, and since the data is coming from the Team's (or Group's) SharePoint site, permissions is not a problem. However, the Team/Group members cannot actually RUN the PowerApp until it's been shared with them. Since PowerApps only allows sharing with individual users or AD security groups (NOT O365 Groups), they need to either share it with each Team/Group member individually OR they need to have IT create an AD security group and populate it with the Team/Group members. On top of that, as people in the Team/Group change, the owner of the App needs to then update the sharing or have IT update the AD security group. This goes exactly against the concept of Office 365 giving users an easy and coordinated way to manage their Teams/Groups and the apps and services provisioned to them.