Forms shared System-wide

[Heather_Kulbacki]

In Setup > Custom Forms

I'm able to add a column to show who each form is shared with. Anyone know of a way to filter to only show those forms that are shared System-wide?

I don't care if the forms are also shared with certain groups, teams, etc, sometimes those groups are needed to give them more than just View access to the form, but I do would like a way to pull just those forms that are also shared System-wide.

As we get more groups who have nothing to do with each other in our instance, I'd like to limit the forms that are shared System-wide to reduce noise for those who need to attach forms to objects.

[skyehansen]

This doesn't answer your question but if you are talking about forms that are "Visible System-Wide" (as opposed to shared system wide), this doesn't add any visibility to the form dropdown (when you select forms to attach).

[skyehansen]

PS: in answer to the actual question, I pulled this out of my library :)

EXISTS:A:$$EXISTSMOD=EXISTS

EXISTS:A:$$OBJCODE=ACSRUL

EXISTS:A:accessorID=PUBLIC

EXISTS:A:securityObjID=FIELD:ID

(and if you're looking for not shared, that would be NOTEXISTS)

[Heather_Kulbacki]

Thanks, I'll give this a try

[Heather_Kulbacki]

"forms that are "Visible System-Wide" (as opposed to shared system wide), this doesn't add any visibility to the form dropdown (when you select forms to attach)."

not sure if we're looking at the same thing or not... when I open a custom form within setup, under Form Sharing and turn off "Visible System-Wide" - that form is no longer available in the form dropdown on the details page of that object for anyone outside of the group(s) that it is shared with.

[skyehansen]

Thankfully, this is not how it works in our instance.

In our instance, "Visible System-Wide" is controlled by the cog in the upper right corner of that rectangle. You can toggle back and forth between "Make this visible system-wide" or "Remove system-wide access". The users in our instance who have this setting on a form can see it when the form is attached to an object, and fill it out. They can't access the form in a dropdown on the details page of that object.

The majority of our forms are visible system wide. To give you some numbers we have approx 200 forms active, of which 8 are not shared system wide. The forms we own that do not get shared system-wide tend to be either "in progress" or financial data.

When a form is NOT shared system wide, and users CANNOT see the form data, this means they also can't use any reports that access this data. Not a big deal as long as your form sharing and user profile is up to date.

I'm always a bit sketchy on the new way custom form sharing works, but my understanding is, aside from "visible system-wide" you can also opt to "Give custom form access to" people, teams, roles, groups, and companies. In my instance, we would do this additional step if we did want to have a particular user or set of users be able to see this in a form dropdown to attach (or auto-attach it by inline editing a report showing a custom form field belonging to this form).

[Heather_Kulbacki]

That is so interesting.

I just tested with a particular project form - setting it to "Visible System Wide"

and made sure the person I'm logging in as does NOT have additional access via either of the 2 groups that form is shared with.

When I log in as her, I can see that form in the custom form dropdown list in Project Details.

Then I went back to that same form, turned off the system-wide visibiltiy and when I log in as her I can't see that form in the dropdown anymore.

I think I'll do some more digging and likely submit a ticket to see what I'm missing. Maybe there's another setting somewhere.

I can see wanting some forms to be visisble to everyone as far as seeing the data both on the object and on reports, but then not wanting everyone to be able to attach that form to an object

[skyehansen]

If you want to hop into the WF-Pro deep dive this afternoon, it's at 12 PT/3ET https://gotomeet.me/wfpro -- we can compare notes, but what I am currently seeing is a disconnect between Classic and New Experience. Our instance is in Classic and it still works as expected -- forms shared system wide are not visible for attachment. In New Experience though, they are. I feel as though this should be classified as a bug -- if you do end up submitting a ticket, can you let me know? And I'll do the same.

[Heather_Kulbacki]

Awesome, I've submitted a ticket (00263059), explaining what you're seeing in Classic and what I'm seeing in NWE and providing a link to this thread.

We went all-in on NWE so I can't get back to Classic anymore to test these things.

I have a confilt that is scheduled until 4ET, but may wrap up early. If it does I'll hop on!

[skyehansen]

thank you! I will submit a ticket and just reference yours.

[skyehansen]

Hey Heather, Sorry we missed you in the deep dive! I don't know if you are experiencing as much pushback with your ticket as we are with ours, but I did some extra digging and noticed that although our users can SEE the forms that are visible system-wide, they still can't attach the form successfully. i.e. the system lets me attach the form but I get an error message on saving it.

Can you let me know if this is the case with your instance? It could help me get a bit further with my ticket. Frankly, if this user account is not able to attach forms that are visible system wide, WHY would they be able to see the form in the dropdown? LOL.

[Heather_Kulbacki]

Skye,

You are correct, those forms that are visible system-wide, but not shared with the user, that user gets the error "You do not have sufficient access to apply form form name" when saving.

I'll add a note about this to my ticket.

This is response I got from our support rep:

"Thanks for your patience as I've been looking into this. After testing in my environment, it does seem like the “Visible System-wide” setting is working differently for users in NWE vs. users in Classic. Where users in Classic only gain the ability to view the form, users in NWE seem to gain the ability to attach the form to objects as well. I am not seeing anything in our documentation that acknowledges this discrepancy, so I've raised this to our engineering team as a potential code bug. I should hear back from them within the next 1-2 weeks with an official will fix/won't fix decision.

I certainly apologize for any inconvenience this is causing. My hunch here is that the Classic experience is actually functioning correctly in this case. It makes sense that you should be able to give "View" access to a user without allowing them to actually attach the form. That said, I'm hesitant to recommend any workarounds until we know for sure how it is supposed to work. That said, let me know if there are any questions or concerns that I can help address in the meantime. "

[skyehansen]

thank you for confirming! On a related note there is new functionality in preview about custom forms attachment‚ÄîI haven’t had a chance to read through and familiarize myself with it but the paranoid part of me says I better before the launch date next week. In Preview I do know that failing to add a custom form will not give an error ... I guess I better dive deeper.

Update -- after reviewing the functionality I'm just going to cover myself by adding one more ticket (just because we are launching 21.4 soon) to indicate that I would prefer that there be a red error message if the custom form attachment fails in any way. Right now there's just an absence of a success message which is not a strong enough indication, and with this potential bug plus any future bugs that may appear, it's not a good user experience to expect folks to understand that the absence of a success[message] is equal to a failure.

Also, just between you, me, and the wall -- functionality predictably (and disappointingly) remains unchanged for those of us who are tasked with creating projects as a shell to assign to other project managers who have the information needed on those custom forms.

[Heather_Kulbacki]

latest from my support rep:

"The engineering team just got back to me on this one, and they've confirmed that NWE is working incorrectly in this case. They've declared this a bug and have committed to writing up a patch to resolve this so that the forms do not appear in the dropdown in the first place. As of right now, the resolution deadline has been set to 6/25. I'll make sure to keep you updated as we get closer to rolling out the fix.

In the meantime, I suppose there is some comfort in knowing that these users don't actually have the ability to attach forms that they haven't been shared on, though it's pretty annoying that they find this out after having filled out the entire form. I certainly apologize for any inconvenience this may be causing in the meantime. Let me know if there are any questions or concerns that I can address at this time."

So that's at least good news, I can go back to leaving "Visible System-Wide" turned on for any forms that it would be helpful for people to see and only sharing them if the user actually need to be able to attach them to an object.

We do have a few forms that we only want a select group of people to be able to see in any way.

[skyehansen]

thanks for the update! Hopefully this means case closed. I'll also follow back up with the documentation folks as the article wasn't much help where Visible System-Wide functionality is concerned. (this is why I didn't just point you to it from the get-go)

Luckily I also gave the NOTEXISTS version of the code up top ;-) -- this will help maintain your much shorter list.