Access level Distribution for Support client Archives - Microsoft Dynamics 365 Blog http://microsoftdynamics.in/tag/access-level-distribution-for-support-client/ Microsoft Dynamics CRM . Microsoft Power Platform Mon, 22 Jun 2020 17:05:53 +0000 en-US hourly 1 https://wordpress.org/?v=6.6.1 https://i0.wp.com/microsoftdynamics.in/wp-content/uploads/2020/04/cropped-Microsoftdynamics365-blogs.png?fit=32%2C32 Access level Distribution for Support client Archives - Microsoft Dynamics 365 Blog http://microsoftdynamics.in/tag/access-level-distribution-for-support-client/ 32 32 176351444 Deployment process flow and Access level Distribution for Support client (Non Technical Explanation not the Current Best Practice ) http://microsoftdynamics.in/2020/06/22/deployment-process-flow-and-access-level-distribution-for-support-client-non-technical-explanation-not-the-current-best-practice/ Mon, 22 Jun 2020 16:47:42 +0000 http://microsoftdynamics.in/?p=3771 Deployment process flow and Access level Distribution for Support client
This is just a Generic Flow Sent to one of a Support client to make them understand how deployment with multi Environment (Prod and Non-Prod) are done in Layman Language as we were Seeing constant change on Production by System Users.
No Development or Customization should be done on UAT and PRODUCTION
Customization roles are never Given to System User or System ADMIN. Customization Roles and Credentials will only be with IT, Admin, and Support Team.
Deployment From DEV to UAT and UAT to Production needs to be followed and should only be done by the Support team or Deployment Team
1. Case Number is registered Support Portal
2. All emails follow-up and requirements should contain Case number in Subject.
3. If ticket Require any FIX/CHANGE/DEVELOPMENT, A new Solution Package is created with the Case number in CRM DEV Environment containing all the development or changed components

The post Deployment process flow and Access level Distribution for Support client (Non Technical Explanation not the Current Best Practice ) appeared first on Microsoft Dynamics 365 Blog.

]]>

Below Process or Steps are not to be implemented for all Scenario and doesn't include CDS as well. This is just a Generic Flow Sent to one of a Support client to make them understand how deployment with multi Environment (Prod and Non-Prod) are done in Layman Language as we were Seeing constant change on Production by System Users.

https://i0.wp.com/microsoftdynamics.in/wp-content/uploads/2020/06/Deployment-Process-microsoft-dynamics-365-crm-project-best-practice-managed-solution--scaled.jpg?fit=2560%2C1528

QUICK SUMMARY

  • No Development or Customization should be done on UAT and PRODUCTION
  • Customization roles are never Given to System User or System ADMIN. Customization Roles and Credentials will only be with IT, Admin, and Support Team.
  • Deployment From DEV to UAT and UAT to Production needs to be followed and should only be done by the Support team or Deployment Team
    1. Case Number is registered Support Portal
    2. All emails follow-up and requirements should contain Case number in Subject.
    3. If ticket Require any FIX/CHANGE/DEVELOPMENT, A new Solution Package is created with the Case number in CRM DEV Environment containing all the development or changed components
    4. Once unit testing is done of DEV by the Support team, Solution Package will be moved to UAT.
    5. After UAT Deployment, System User will be informed to Test Fix and change.
    6. If System User Failed the Testing, Fix will be done in Dev first and then only moved to UAT for retesting
    7. If the System User Test is Successful, the Support team will send Deployment Document with Required component and Fix details
    8. Once the Document is signed by System User, the Support team will Deploy Solution from UAT TO DEV.
    9. Validation will be done by the Support team and Confirmation will be sent once done.
  • Once Deployment is done, or the Issue has been resolve Case will be closed.

Deployment Process (Again for Non-Technical System Users)

Microsoft dynamics 365 CRM ProjectName has multiple instances i.e. DEV,UAT and PRODUCTION and support/dev team need continuous fixes/development releases to Production and as explained in below process,

  1. Development can only be done in DEV that can include
    – Entity, Fields, Relationship, Optionsets
    – System + Custom Templates
    – Process/Flow/Codes/business rule/web resources
    – Security roles, Field Security, Reports, System Settings, Configurations
    – Forms, views, charts, dashboards, Sitemap
    – E.T.C
  2. No Development or customization can be done on UAT: UAT is for Integration + process + Performance testing
    – All Customization + Confirmations need to be moved from DEV to UAT using Solution Package and Configuration Migration
    – Can only Map Transaction data to Configurations Example In Approval Process actual or test Approvers user can be mapped in UAT
    – No Dashboard Change, No Charts Change, No Configuration change, No field mandatory non-mandatory Change,No security role change, No email Template, No Workflow Change, No Field Creation, No Report change, No System Settings, No System or Custom views changes can be done directly on UAT
  1. PRODUCTION: All customization + configurations need to be moved from UAT to PROD using Solution and configuration migration package deployment.
    No Development or Customizations of any type can be done on Production
    NOTE: To prevent this as per standards, Customization roles are never Given to System User or System ADMIN. Customization Roles and Credentials can only be with the IT Admin and Support Team and can only be used in the presence of the Support Team.
    Also, Customization Role Removal doesn’t remove Charts, Dashboard or advance find Rights. System admin can still be Accessible by system admin.

Key Roles and Permissions on Environments

Below are the issues/Problems which can occur if we don’t follow standard Deployment process and Stockholder Access Levels

  1. For smooth DEV -> UAT -> PROD Fix deployment i.e to prevent solution errors and issues post-deployment.
  2. Prevent Missing Dependencies and overwriting existing important customization
  3. GUID can be different which can break integration or approval process
  4. Performance issue
  5. Troubleshooting can take more time than usual and Downtime can increase so user cannot access Production
  6. Unequal multiple environments will result in no Fix Deployment and unexpected system behaviors and would be difficult to troubleshoot

Below are the Stockholders, Login Access and Permission as per standards

 

The post Deployment process flow and Access level Distribution for Support client (Non Technical Explanation not the Current Best Practice ) appeared first on Microsoft Dynamics 365 Blog.

]]>
3771