Office 365 groups are available with Dynamics CRM Online who don’t use CRM. In simple words, Sales team don’t have access to input important input from various people. Office 365 in this case provided a collaborative location to share documents, conversations, meetings and notes. Office 365 groups can be enabled for any entity. Important: Users must have an Exchange mailbox setup. Also, Server-based SharePoint Integration needs to be enabled to be able to see the documents. Provision Office 365 Groups Preview Navigate to Office 365 admin center, choose CRM as shown below. Then choose, Solutions. Then choose, Office 365 Groups and then choose Install. Review the terms of service and then choose install. Once installation is complete, you can configure Office 365 Groups. Check Required Privileges The security privilege, ISV Extensions, is required to use Office 365 Groups. You can add or remove this privilege from custom or default security roles to meet your business needs. If a user does not have this privilege, they will not be able to see the Office 365 Groups item in a record’s navigation menu. Configure Office 365 Groups In CRM Online, navigate to Settings > Office 365 Groups. On the settings page, choose Add Configuration and choose the entity. Auto-create can also be chosen if you wish to create O365 Group to be automatically created. Finally, choose Publish All. Hope this was helpful. Thank you.

Before release of CRM 2015 Update 1, user needs to call different request to perform the below operation. 1. If user wants to update the records he needs to call the UpdateRequest 2. If User wants to Change the Status of record he needs to call the SetStateRequest. 3. If a user wants to change the ownership of the records then also he needs to perform the AssignRequest. 4. Similarly user needs to call below request to perform the below operation So, if user needs to perform below operation on a record, a: Update b: Assign c: Status Then user needs to call three different request which hits the server thrice and if there are so many records then it will increase the load. But in this release there is good news for the developer, now user can perform all the above operation in a single request. User just needs to call the UpdateRequest to perform all the above listed operation. Notes: For Microsoft Dynamics CRM Online organizations, this feature is available only if your organization has updated to Dynamics CRM Online 2015 Update 1. This feature is not available for Dynamics CRM (on-premises). Though above listed messages have been deprecated for future releases, it will continue to be available with the 2011 endpoint. However, the recommendation is to use the UpdateRequest or Update method when possible to set these attributes. You can continue to use these specialized messages of the 2011 endpoint in your code. However, the Web API that eventually replaces the 2011 endpoint supports only the Update message for these types of operations. If you want to get a head start on changing your code to align with the Web API, you can now do so. See Web API Preview for more information. Following are the impacts on the Plug-ins and workflows Plugin: When update requests are processed that include both owner fields plus other standard, plug-ins registered for the Update message in pipeline stage 20 and/or stage 40 execute once for all non-owner fields, and then once for the owner fields. The new API would not execute the SetState or Assign message plugin, BUT, it will call an UPDATE request for each of these messages a. 1st time for the updating-This time, the target would receive only the non-owner/non-status fields) b. 2nd time for the Owner-only the owner field is available in Target c. 3rd time for the state-This time only status fields are passed in Target. In order for plug-in code to receive the full data changes of the update, you must register the plug-in in stage 10 and then store relevant information in SharedVariables in the plug-in context for later plug-ins (in the pipeline) to consume. Workflow: a. When update requests are processed that include both owner fields plus other standard fields, workflows registered for the Update message execute once for all non-owner fields, and then once for the owner fields. Workflows registered for th Assign message by users continue to be triggered by updates to owner fields. b. When update requests are processed that include both state/status fields plus other standard fields, workflows registered for the Update message execute once for all non-state/status fields, and then once for the state/status fields. Workflows registered for the Change Status step continue to be triggered by updates to state/status fields.