Solution import export

[ravdemo]

Which is a best practice of customization: do we need to import solution into sandbox environment as an unmanaged solution from production environment and then after export as a managed to production environment? Should a clone to patch and clone a solution is better option? will all the records created by a user in production during our time in customization and upgrade to newer managed solution will be lost or will stay?? Thank you 

[Pstork1 · Accepted solution]

The best practice would be to develop the Solution in a Developer or Sandbox environment to begin with. then when ready to deploy to production export the solution as a managed solution and import it into Production. If you want you can also import it into a test or QA environment before importing to production.  If you already developed it in production then export it as an unmanaged solution and import it to a developer environment. After making changes delete the solution from the production environment and import a managed solution back to production. The unmanaged solution should remain in dev.

[parvezghumra · Accepted solution]

@ravdemo Best practice states that all customisations should be made within an unmanaged solution in the dev environment, this should then be exported as managed and imported into non-development (ie. test and Production) environments.

Patches are no longer recommended for use by Microsoft. They were originally introduced into the solution framework in order to optimise the deployment experience. But now that they have significantly improved the performance of managed solution deployment and because patches introduce unnecessary complexity, their use is no longer recommended.

The upgrade of a managed solution in a non-development environment can only result in the loss of data when the new version removes any schema (tables, columns, relationships). For example, if a table component is removed in the new version of the solution, the upgrade will result in the deletion of all data in that table in the target environment. Likewise, if a column is removed in the new version, the upgrade will result in the deletion of all data in that column in the target environment.

[johnnylo]

I followed the dev environment first approach and imported my canvas app as managed solution into default environment.  After import, there is connector configuration error when running the app in the default environment.  Posts on forums and docs on microsoft (at least those that I manage to find) suggest to edit the connector references, which I am unable to do on the solution in the default environment.  The Edit option is tinted.  I can however edit the app directly and publish it.  But the same errors persist.  I believe the fix is to edit the solution?  What permission am I missing?  I will be sharing this app with a few other users.  I had make sure they have read access to the flows involved in

the same environment and read access to the PowerBI dataset that one of the flows uses.

[Velegandla]

@johnnylo 

I followed the dev environment first approach and imported my canvas app as managed solution into default environment. 

Recommend you to move your solutions from Dev environment to a dedicated Prod environment not to a default environment.

After import, there is connector configuration error when running the app in the default environment.  Posts on forums and docs on microsoft (at least those that I manage to find) suggest to edit the connector references, which I am unable to do on the solution in the default environment.

Ideally you don't have to edit the connection references. Can you post the error the message here?

You should try to fix it in Development environment. 

Last option you could try: All artefacts (including connection references) of solutions will be available in "default solution" and you can edit the reference from here.

I will be sharing this app with a few other users.  I had make sure they have read access to the flows involved in the same environment and read access to the PowerBI dataset that one of the flows uses.

You can share the apps and Power BI dashboard. No need to share the flows with users unless they need to manage those as owners. There is no read access to flows.

====================================================

If this response helped you in any way, please give kudos by clicking the 'Thumbs Up'/'Like' button and/or marking it as an 'Accepted Solution'. This helps others by providing a quick way to identify likely solutions to their issues.

https://www.linkedin.com/in/devendravelegandla/ 

[johnnylo]

@Velegandla Thank you for your respond.  Yesterday afternoon, for some magical reason, everything works as it expected.  Someone told me sometimes there is lag time on Azure.   How can we checke that status during development and deployment?

About read access to flows.  In PowerApps navigatioin > Solution, then in my solution object list, in Detail of a flow objects, there is a Run only users setting.  I had this set to the user I want to give access to on all the flow.  That is now removed.  Could removing this setting the reason why there is no Connection not configured error?  I wish I had the exact wording of the error while it was still occuring.

[johnnylo]

This is the flow detail page where it contains a Run only users setting

[Velegandla]

@johnnylo 

You can check the Azure status using the link https://azure.status.microsoft/en-us/status .

Add it to your deployment checklist.

Run only User feature in Power Automate:

You can use this feature to run the flows based on one account rather than the user's account triggering the flows. This has nothing to do with access to the flow.

This setting will be used if you elevate the privileges and perform actions for users. 

====================================================

If this response helped you in any way, please give kudos by clicking the 'Thumbs Up'/'Like' button and/or marking it as an 'Accepted Solution'. This helps others by providing a quick way to identify likely solutions to their issues.

https://www.linkedin.com/in/devendravelegandla/ 

[ON-Eagle]

Jump in a quick question for @parvezghumra : "Patches are no longer recommended for use by Microsoft. They were originally introduced into the solution framework in order to optimise the deployment experience. But now that they have significantly improved the performance of managed solution deployment and because patches introduce unnecessary complexity, their use is no longer recommended."

so if we have only a minor change in dev, e.g. change a table main Form, and we want to deploy this to production env, what should we do if not to used the solution patch? right now we create a temporary solution, e.g. App_name_bugfix, and add the modified Form component to it, then export/import this  temporary solution to prod. at some point later ( after a major development ), we deploy the main solution to prod, which already contains the changes in the temporary solution "App_name_bugfix", then after the deployment, we delete the temporary solution in prod. Is this a good practice? if not, what's the method to deploy minor changes to prod? as we don't want to deploy the main solution everytime for a bug fix. Thank you! 

[parvezghumra]

@ON-Eagle Apologies for the delayed response.

The approach you have described is valid. The only thing you need to be careful about with this approach is to ensure that the objects included in your 'temporary' solution do not contain any changes or objects that are not ready for deployment.

Ideally, if you have adopted a fully source control centric approach, you could branch your code base based on the build that is in the Production environment. This branch can act as your maintenance/hotfix stream and can then be used to spin up a corresponding development environment for you to make your bug fix in. You can then deploy the entire solution from this environment confidently as you know that the delta between the Production environment and this solution you are exporting from this environment is just the change you have made for this bug fix. This approach can be a lot of overhead though.

I'm curious as to why you don't wish to deploy the entire solution though. If it's due to the time it takes to deploy the managed solution, there are a couple of other things you should consider:

1. Try to remove any bloat from your solution to reduce it's size and complexity. Generally solutions should only contain custom objects or objects you have customised. Sometimes creating relationships with managed tables can cause the platform to bring in the entire target table including all assets into your solution without you knowing. Use the 'Solution Table Integrity Manager' tool from the XrmToolBox to identify such problems and resolve them. This will help reduce the size of your solution

2. Consider breaking up your solution into smaller ones. This can give you more granular control over the deployment cadence of the solution. Be careful of any dependency issues this may cause though.

3. Use the 'Update' option and don't use the 'Overwrite unmanaged customisations' or 'Convert to Managed' options. This will significantly reduce your managed solution import times. These should be your default configuration for regular managed solution imports, but then every once in a while I would recommend doing a managed solution import using the 'Upgrade' option with 'Overwrite unmanaged customsations' checked - this will ensure your environment is clear of any deprecated objects and isn't littered with unmanaged changes.