Andrew Friebel

Currently there is no way that we can remove an organisational user from LCS.  If we add an organisational user for LCS, we can see them added.  The removal process is to disable on AAD and to remove them from Customer/Partner source.  That may prevent them from accessing LCS, but as a user, they still remain in LCS.

We should be able to remove LCS users for users who are no longer part of our organisation.  It's a cleanup process that hasn't been properly completed in LCS.

Regards,

Andrew

The development VM is currently provisioned with a limited number of hard drive space on the service volume.  Developers like to experiment and push the system to the limits to know what it can or can't do.  I'd like to suggest that provisioning the dev box service volume with the same space as UAT boxes would enable developers to do more of this.

It would be good to be able to import a binary hotfix into your asset library directly from the binary hotfix page.  At the moment, you download it (which is an option that will always be required), then upload the zip file into the asset library.  It seems a bit of a waste of time to do this two step process, it would be great to be able to have an option that allows you to push it directly there.

The LCS version capability for the asset library is a step in the right direction, but it has limitations.  Some useful additions would be:

• Ability to add/edit version description
• Release notes can only be added when the file is added, you need to be able to provide the ability to add/update release notes, even after the file has been uploaded
• Ability to be able to delete a version (in case the file was initially incorrectly selected to begin with).

Further to this, the ability to delete assets which are no longer in use is a requirement, otherwise your asset library simply continues to build up with irrelevant assets.  If I have an asset for 7.1, then load a new asset for 7.2, the old asset is no longer relevant when all environments are at 7.2, and as such, it should be able to be deleted.

Another example - I deploy an asset to a PAYG environment (to test/demo), then delete the PAYG environment, the asset can't be deleted, even though it's no longer relevant.  Irrelevant items in LCS asset library gets confusing.  Basic cleanup functions of LCS need to be allowed by those administrating the library.

The functionality that currently shutdowns a VM works, but it is not seamlessly integrated into LCS.  I can schedule a VM shutdown through Azure, and the VM will shutdown.  However, when I am in LCS, there is no way to tell that the environment is shutdown.  I'd like to see LCS check the status of the VM and determine if it's up or down, and report the status correctly.

At present, to restart the environment, I have to shut it down in LCS (even though it is shutdown aleady), then start it.  To have LCS be able to see the status correctly would make the link between Azure and LCS more seamless than it currently is.

The current process of automatically shutting down an environment when not in use is cumbersome.  LCS should be the single source of managing an environment for D365FO.  As such, it would be good to see a shutdown/startup schedule in LCS that would create the required Azure shutdown and startup scripts.  This way administrators wouldn't need to worry about going into the Azure portal to manage shutdown automation.  This would help make LCS a one stop shop for D365FO administration.

When creating a new data entity, if the primary key on the target table is 'RecId', the wizard will throw an error about no natural key.  While the uniqueness is important, I think rather than the wizard forcing the primary key uniqueness, it would be good to give the option to define the uniqueness of the data entity within the wizard.

There are many MS tables that still have the primary key as the 'RecId', which makes development of a new data entity for those tables rather annoying in having to get around this issue.  I think if the wizard gave the option to define the uniqueness on the fly, then it would allow a better mechanism for the data entity development.

The full application version to be displayed on the environment page on LCS. Currently, if you have an environment on application version 8.1.3, LCS will only display 8.1. From an environment management perspective, the LCS displayed version does not give enough detail for the environment manager to know if particular fixes are in that version. If an environment is on application 8.1.3, then LCS should reflect that. To get that detail, you need to log into the environment, go to 'About' find the version detail for the application suite, then go to an MS website which lists all the version, cross reference the build number with that that you got from the version of the application version, then you can work out what application version an environment is on. That's simply too many steps to get the correct version number.