Developers: Prepare for More Security Work When Upgrading to Microsoft Dynamics AX 2012

November 10 2011

In a special AXUG Summit breakout session on security, FastPath's Mike Cassady and Arbela Tech's Carsten Glem tackled the thorny issue of maintaining security for Microsoft Dynamics AX. Users and developers in the audience drove the conversation, asking questions about and sharing solutions for problems such as restricting security at the record level, generating comprehensible security reports and testing changes in security profiles.

About Heidi Kyser

I’m a freelance writer in Las Vegas. I’ve been a journalist for 11 years, starting as a news editor at trade journals (Tradeshow Week, World Tea News), and recently becoming a regular contributor to regional magazines.

More about Heidi Kyser


Dixiecrat's picture

I'm a little shocked that this is being reported as such, and that the response to customer was what is stated in this article. This is very much a great improvement and not a heavier load on the developer. This is a Fnctional design point, and should be viewed as such.

jgumpert's picture

Take a look at our follow up piece on this topic: Where we look at Brandon's full response to the topic of designing security policy into the implementation of Microsoft Dynamics AX 2012.

jdegruyter's picture

I'm surprised how this is being portrayed in this article. Yes, the upgrade path for security is not great, but from where I am standing as a technical implementation consultant, my clients would be happy to throw out their existing setup for something more structured and robust. Yes, it will take a bit of figuring out how to fit into the existing roles. But even if you need to create new roles, you can pick and choose high-level duties from a list and not fiddle with a mess of security keys and implied inheritance structures. For upgraded custom code you will need to add security. If your custom code is that heavy that you have a ton of work on security, you will have a tough time upgrading the code itself to 2012 already, and should probably re-evaluate the whole modification anyway, security being a minor detail. As for new customizations, any good design specifies the restrictions of the modification. There is now a NEED rather than a best practice to specify the security implications of a modification. This is part of a good design, and is an extra step for the analyst writing an FDD. The impact on a developer is minor. If the developer is having to come up with the security model for his modifications, you're on the wrong path.