Customer Engagement & Dynamics CRM Forum

Expand all | Collapse all

Is using GUID a good code practice.

  • 1.  Is using GUID a good code practice.

    Posted Nov 05, 2019 07:32 AM
    Fellow Coders

    Is hard coding guids a good code practice with regards to Crm records? I know that MS has provided us Alternate Keys that we can assign fields to, but would like to know if there are any technical pitfalls to using the actual guids.


    Rex Kenley Tan, MCSA, MCSD
    Tallmadge OH

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    Academy - Online Interactive Learning from Experts

  • 2.  RE: Is using GUID a good code practice.

    Posted Nov 05, 2019 12:30 PM

    @Rex Kenley Tan I have attempted to stay away from this because of cross environment issues with new records. I promote changes from DEV to UAT, and then to Prod. In the case of a new record, lets say a category, if i make the record in DEV, and then code against the GUID, when i promote, the GUID changes because I have to recreate in UAT the record. Once ultimately in Production, I would have changed by hardcoded GUID 3 times, which can be a pain.

    The other issue, is if the referenced GUID record is deleted (hopefully not...) or if the referenced record needed to be changed. In both of those instances you may have a hard time tracing all the instances you referenced a hardcoded GUID over a field (even hidden) that could dynamically set the attribute, retrieved over the API, and could update dynamically. Generally, that is my approach when coding is to create fields to provide me with a way to retrieve the record and just not place the fields on the form, and hide them from search, that way i can update the records as needed without having to go back to my code base.

    I am interested in what other people think on this as well. 

    Erik Seitz
    RJ Corman Railroad Group, LLC
    Nicholasville KY

    Academy - Online Interactive Learning from Experts

  • 3.  RE: Is using GUID a good code practice.

    Posted Nov 06, 2019 02:36 AM
    Hi Rex

    I've brought this issue up with platform reps ​at MS, and from a technical perspective there are no recommendations against this. It will simply just save the internal pipeline from another Guid.NewGuid() call.
    Of course there could be other aspects on how you intend to take advantage of this, as @Erik Seitz mentions.


    Jonas Rapp

    Academy - Online Interactive Learning from Experts

  • 4.  RE: Is using GUID a good code practice.

    Posted Nov 06, 2019 08:42 AM
    For the most part I recommend not using hard coded Guids for referencing entities because it's to easy for the Guids to not be accurately maintained between environments and obviously having to have different code per environment is a no-no.  In this area, creating an alternate key is a wonderful solution to be able to reference an entity, and allow for an easier method to keep the data accurately maintained between environments.  Plus guids are created in SQL sequentially to help with indexing, so if you are putting in your own custom Guids, it would (theoretically) run slower (a tiny, tiny, tiny, tiny, tiny amount).

    The one area where I recommend on violating this rule, is when the Guid is associated with solution deployments.  The most obvious case for this are User Roles.  Roles are solution aware and should be migrated from the dev environment to all other environments.  Then (usually in JS) when you're attempting to figure out if a user has a particular role, the Guid, is much better than the name.  Of course these guids should be assigned to a constant with a good name so you know what the heck you're referring to in the code.

    Just my $0.02.

    Daryl LaBar
    President, MVP
    Gap Integrity
    Fishers IN

    Academy - Online Interactive Learning from Experts

  • 5.  RE: Is using GUID a good code practice.

    Posted Nov 07, 2019 01:37 PM
    I;m checking through our Plugin Code and don't see much use for using the Guid.  There are some places where using the Guid makes sense.  One way in which we utilize it is when we are looking for specific Users within a Plugin.  For instance we have a User dedicated to not processing Plugin Code for bulk updates when we want to avoid triggering Workflows and other Plugins.  We will compare the context.UserId to the User's Guid and exit the Plugin if it matches.  Since we do Backup.restores to our Dev enviornments the User's Guid is the same for all environments.  The same goes for Team, Workflow etc.

    A second instance is creating custom numbering for Tables.  An IOrganizationService.Retrieve is much faster then an IOrganizationService.RertieveMultiple in getting to the Master Table to grab the latest Number.  Since the Plugin is performing a Lock on the Record before updating, the quicker we can Retrieve, Update and exit the Plugin the better.

    A third place I find using the Guid to be useful is using the API's built in Import feature to avoid duplicate errors.  For instance, I have many inactive Accounts through Merges that have the same name.  But since the Import doesn't omit inactive records when searching for Duplicates the Import fails to update the Record because it can't resolve the Lookup.  Putting the Guid in the Excel Worksheet solves the problem since it is guaranteed to be unique.

    I am sure there are other places that it would be useful to use but these three immediately came to mind.

    Gerry Yurko
    CRM Developer
    Lightower Fiber Networks
    Boxborough MA

    Academy - Online Interactive Learning from Experts

If you've found this thread useful, dive deeper into User Group community content by role