Change Visibility of Attributes on Visible Sections Only

When changing the visibility of attributes in Dynamics 365 or Power Apps, you might have noticed that this change also impacts hidden sections, where the attribute is located, i.e. these sections are set to visible by default. While this of course makes sense, it might not always be what you intended, especially if you used attributes with multiple instances within a form.

For instance, as you can see in the following illustration, the visibility of sections in our order form is determined by product selection (sand or bricks). The section “Product Details” is individual for each product, though in both cases it allows the user to choose a unit (kg or m3). Upon selecting kg as “Unit (Classic)” in “Sand Details” the visibility is set for the attribute “Weight” (resp. “Volume” if you chose m3), which then appears on our form.

Example of a material order form with hidden sections appearing on attribute visibility change

But – lo and behold – what is this?! The section “Bricks Details” is also suddenly visible on our form. How did this happen?

See, as “Brick Details” contains the attribute “Weight” as well the whole section is set to visible by default. Of course you could override this by using unique control names, like “weight_2” etc., and set the visibility individually for each item. While this could work for a while, it is not the safest option development-wise (think reusability and clean coding) and will definitely cause problems as soon as changes are made to the controls or if attributes are used more than once.

Let me show you a better option.

As stated, our aim is to apply attribute visibility only to controls on already visible sections. We can achieve this by checking in the event handler beforehand, whether the control we want to set to visible is located on a visible section. If the section is visible, the control will appear. Any other invisible sections, which contain controls of the same name, will remain hidden. This way, section visibility will not be implicitly affected.

Let’s have a look at the code.

static setVisibilityOfAttributeOnVisibleSectionsOnly(fCtx: Xrm.FormContext, attributeName: string, isVisible: boolean) { // Get the names of all controls on visible sections var controlNames: string[] = []; fCtx.ui.tabs.forEach(t => t.sections.forEach(s => { if (s.getVisible()) { s.controls.forEach(c => controlNames.push(c.getName())); } })); // Change the visibility for the control of the attribute. fCtx.getAttribute(attributeName).controls.forEach(x => { // But only if the current control is on a visible section if (controlNames.includes(x.getName())) { x.setVisible(isVisible); } }); }

And this is what it looks like in our app. Note that now, when you select kg as unit on “Sand Details”, the attribute “Weight” will show on this section – while our alternative section “Brick Details” will remain hidden.

Example of a material order form with hidden sections remaining hidden on attribute visibility change

In a nutshell, if you aim to avoid problems in the long run, the proposed solution is a good way to go. You can use (and reuse) attributes of the same name/type without worrying that it might impact the intended functionality. Using this function will enable you to build forms with multiple sections and still control exactly which of your data will be presented.

Let me know, if you have already encountered this matter and if this solution helped you.


Blog post written by

Henning Schumacher

Hennning Schumacher is a Microsoft certified technical consultant focusing on the Power Platform and cloud-native application development on Azure. As a seasoned developer his fields of expertise are databases, business intelligence and custom coding, especially in C# and JavaScript/TypeScript. If you would like his assistance in solving your challenges drop us an e-mail and we will get back to you.

Du begeisterst dich für Softwareentwicklung, hast Erfahrung mit Microsoft Technologien und suchst nach einer neuen Herausforderung? Sieh dir unsere offenen Positionen an!

(Senior) Power Platform Developer (m/w/d)

Unterstütze unser Team in der Entwicklung anspruchsvoller Lösungen - in Paderborn, Hamburg oder remote. Mehr