A CRM project of 3 to 6 months’ time is a good medium sized project, a medium scale organization looks for. It allows them to do proper resource allocation and extend their horizon to showcase their talent to bring out the best from the venture. But, this needs to be handled well with a full time PM dedicated for the project. Along with this the entire project cycle has to be ethically followed. Below is a step by step quick guide that can help a successful CRM Implementation for such projects to be done. 1. Prepare a project proposal and get the Sign – off/Approval on the hours estimated for the bifurcated tasks from client. 2. Create a Project Charter to assign a Project Manager to the project. 3. Allocate the resources needed. Here we carefully do a right mix of senior resources vs junior resources to develop the project. 4. Once the above is fixed the PM needs to prepare a project plan. Allocate the resources at task level. (Use MS Project for creating project plan). 5. Get the environments ready to start the work. Ideally we need 3 environments for the entire project life cycle: a. Dev Environment – Where developer carry there development activity. b. UAT Environment – Where Client performs test for the development done. c. Production Environment – Where the final product shall be deployed. 6. Since the development happens in Phases for a CRM project, we can follow “Agile Methodology” for development of CRM application. Following are the phases in which the development is carried out: 1. Design Entities. 2. Design Views. 3. Design Forms. 4. Create users in CRM. 5. Assign Business Units and Security Roles to the users. 6. Write Scripts/Business logic. 7. Write Plug-in’s if required. 8. Write workflows. 9. Do any Third Party integration – If Required. 7. With the above phases defined we can split then into 4 phases. Phase 1: (CRM Look and Feel) > Design Entities. > Design Views. > Design Forms. Phase 2: (User Security Roles & Business Unit) > Create users in CRM. > Assign Business Units and Security Roles to the users. Phase 3: (Business Rules) > Write Scripts/Business logic. > Write Plug-in’s if required. > Write workflows. Phase 4: (Any Third Party Integration) 8. For all the 4 phases defined above schedule UAT’s as and when they are finished. They should be defined as milestones in the project. 9. Each phase should be minimum of 1 week’s duration, which includes bug fix if any. (Depending upon the complexity and size of the project). They should also be reflecting in the Project Plan. 10. With all of the above set follow the Project development methodology defined. 11. After we are done with the Requirement Gathering Phase of the project which might be a littles exhaustive as we need to have call with the client for more than 3 days a week. 12. Post the requirement gathering phase is complete and we are in actual development phase we need to do a couple of things in order to proceed: a. Document the Function Requirements and prepare a “FRD (Functional Requirement Document)”. b. Simultaneously with project development prepare a “TSD (Technical Specification document)”. c. Schedule a bi-weekly call with the client to provide status update and also discuss on other requirements if any. 13. Ask the client to create User Test cases for all the entities. Hand over the same to us 1 week in advance before each phase is pushed to UAT. 14. After each Client meeting do make it a point to send out precise Minutes of meeting. 15. Every week once send a status update and work review report to the client. 16. At any point of time the project should have a following set of updated documents to refer to: a. FRD – Attached with CR’s. b. TSD c. Project Plan (MS – Project) d. One Note: This contains the following other project related information like i. Environment Details/ Credentials. ii. Agenda’s for each project meeting schedules. iii. Minutes of Meeting. iv. TO DO’s/ Tasks for the team. e. Issue Tracker Sheet. (Shared with the client) 17. At the closure of the project we should have the following documented and preserved as companies knowledge base: a. Learnings from project. b. Issues/ Challenges faced.

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.