{"id":41587,"date":"2025-06-23T15:46:18","date_gmt":"2025-06-23T10:16:18","guid":{"rendered":"https:\/\/www.inogic.com\/blog\/?p=41587"},"modified":"2025-06-23T15:46:18","modified_gmt":"2025-06-23T10:16:18","slug":"retrieving-masked-field-values-programmatically-in-dynamics-365","status":"publish","type":"post","link":"https:\/\/www.inogic.com\/blog\/2025\/06\/retrieving-masked-field-values-programmatically-in-dynamics-365\/","title":{"rendered":"Retrieving Masked Field Values Programmatically in Dynamics 365"},"content":{"rendered":"

\"Retrieving<\/p>\n

Are you working on a Dynamics 365 Customer Engagement (CE) project and struggling to integrate a payment system that requires access to sensitive data\u2014like a customer\u2019s full bank account number?<\/p>\n

You\u2019re not alone.<\/p>\n

Imagine this: you’re developing with backend plugins, operating under elevated privileges, and fully expecting the System Admin service to give you unrestricted access. But instead, you hit a wall\u2014no matter what you try, the masked field remains partially hidden.<\/p>\n

Sound familiar?<\/p>\n

That’s because Dynamics 365 enforces data masking even in backend code, leaving many developers puzzled and looking for solutions. Let’s dive into what\u2019s really going on and how to approach this challenge.<\/p>\n

The Issue: Getting Only Masked Values<\/strong><\/p>\n

In many cases, the customer\u2019s bank account number might be stored on the account entity. But when the user runs your payment processing plugin, you\u2019re probably seeing field values like this: `****5678`.<\/p>\n

Frustrating, right?<\/p>\n

Despite having backend access, the field remains masked, making it impossible to retrieve the full value directly, even through the system admin service.<\/p>\n

Here\u2019s what the code looked like:<\/p>\n

Entity account = service.Retrieve(\"account\", accountId, new ColumnSet(\"new_bankaccount\"));string accountNumber = account[\"new_bankaccount\"].ToString(); \/\/ returns ****5678<\/pre>\n
This was clearly a problem\u2014the payment gateway needs the actual account number<\/strong>, not a masked one. As a result, the entire payment workflow was failing.<\/p>\n
What You Should Know About Field Masking in Dynamics 365:<\/p>\n
Through your own testing and a deep dive into the documentation, you\u2019ll likely uncover a few key insights that explain why sensitive fields\u2014like bank account numbers\u2014stay masked, even when accessed through backend code.<\/p>\n
    \n
  1. Masking applies globally<\/strong> \u2013 It\u2019s not just a front-end\/UI feature. Even backend processes like plugins retrieve masked values.<\/li>\n
  2. Plugins run in user context<\/strong> \u2013 So if the user doesn’t have permission to view unmasked data, your plugin won\u2019t either.<\/li>\n
  3. Automation can break silently<\/strong> \u2013 Masked fields can cause critical background processes (like payments, validations, or data exports) to fail or behave unexpectedly.<\/li>\n<\/ol>\n
    The Workaround: How to Access the Full Value<\/strong><\/p>\n
    After extensive trial and error, two effective methods were identified, depending on the context in which the data is being accessed.<\/p>\n
      \n
    1.  For APIs, JavaScript<\/strong><\/li>\n<\/ol>\n
      If you’re accessing data from the front-end (i.e form scripts), you can retrieve unmasked values of any masked fields by adding a special query flag:<\/p>\n
      GET \/api\/data\/v9.2\/accounts(GUID)?$select=new_bankaccount,new_creditcard,new_customfield&UnMaskedData=true<\/pre>\n
      Note: If you want to unmask all the configured fields, it can be done using the same query\u2014there’s no need to add any additional attributes.<\/strong><\/p>\n
      Important: This works only on the front-end (JavaScript, Web API, etc.). It does not apply to server-side code such as plugins, workflows, or custom C# code \u2014 those still return masked values unless accessed using system context.<\/strong><\/p>\n
        \n
      1.  For Plugins and Workflows (System Context)<\/strong><\/li>\n<\/ol>\n
        Since plugins run in a specific user context, you need to switch to SYSTEM Context<\/strong> by creating a service using CreateOrganizationService(null)<\/strong>. This essentially executes the call as the SYSTEM<\/strong> user itself.<\/p>\n
        Here\u2019s how to retrieve the unmasked value inside the plugin:<\/p>\n
        public Entity GetUnmaskedBankDetails(Guid accountId, IOrganizationServiceFactory factory)\r\n{\r\n    \/\/ Create system-level service\r\n    IOrganizationService sysService = factory.CreateOrganizationService(null);\r\n    return sysService.Retrieve(\"account\", accountId, new ColumnSet(\"new_bankaccount\"));\r\n}\r\npublic void Execute(IServiceProvider serviceProvider)\r\n{\r\n    var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));\r\n    var factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));\r\n\r\n    Entity account = GetUnmaskedBankDetails(context.PrimaryEntityId, factory);\r\n    string fullAccountNumber = account[\"new_bankaccount\"].ToString();\r\n\r\n    if (!ProcessPayment(fullAccountNumber))\r\n    {\r\n        throw new InvalidPluginExecutionException(\"Payment processing failed.\");\r\n    }\r\n}<\/pre>\n
        This approach gives access to the actual bank account number<\/strong>, and the payment processing system started working as expected.<\/p>\n
        Conclusion:<\/strong><\/p>\n
        When working with masked fields in Dynamics 365, standard access methods won\u2019t reveal full values.
        \nUse ?UnMaskedData=true for front-end\/API calls and CreateOrganizationService(null) for backend plugins.
        \nThese techniques ensure secure access to unmasked data without breaching security protocols.
        \nAlways apply them thoughtfully to maintain compliance and data integrity.<\/p>\n
        \u00a0<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
        Are you working on a Dynamics 365 Customer Engagement (CE) project and struggling to integrate a payment system that requires access to sensitive data\u2014like a customer\u2019s full bank account number? You\u2019re not alone. Imagine this: you’re developing with backend plugins, operating under elevated privileges, and fully expecting the System Admin service to give you unrestricted\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":15,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[16,2361],"tags":[533],"class_list":["post-41587","post","type-post","status-publish","format-standard","hentry","category-dynamics-365","category-technical","tag-dynamics-365"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts\/41587","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/comments?post=41587"}],"version-history":[{"count":0,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/posts\/41587\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/media?parent=41587"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/categories?post=41587"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inogic.com\/blog\/wp-json\/wp\/v2\/tags?post=41587"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}