Why Doesn't Portal View Show Dynamic Forms and Custom Fields Even When Dynamic Rules Are Used?

For context, I primarily work with Service Desk for Change Management documentation and ticketing. Despite having created custom fields that are set to be visible in Portal, added them to dynamic forms which are also set to be visible in Portal, and enabled the forms using dynamic rules these fields are not visible in Portal to any of my users. I have my dynamic rules set to display the form whenever one of the eight categories are selected, so it's always going to be pre-selected when the user clicks on the catalog item and makes the request, therefore the customer forms should always be visible. However, the only fields visible are Requester, CC, and the option to Attach Files (as configured elsewhere in SWSD).

I have read other threads on this topic, with statements from SW representatives advising that custom fields, dynamic forms, and dynamic rules should work in Portal if configured correctly. Through a live chat discussion with an expert in the ServiceDesk application itself, I was told that only process fields are visible in Portal. I would like to move forward with my change management ticketing projects, but I need clear information about what options are available to me within Service Desk.

Related threads:
Custom fields not reflecting in change form
Using Dynamic Forms, Custom Forms, and Custom Fields

  • Howdy  

    This point of confusion has come up before. The Forms and Fields you're creating are on the Incident and/or Change level. On the portal side, what the end user is interacting with is a Catalog Item, either from the Service Catalog or Change Catalog.

    Those objects do not show Dynamic Forms. Instead, they rely upon the Inputs or Process Fields built at the Catalog Item level. Once the end user submits it, the Dynamic Forms kick in because at that point, it moves from being a Catalog Item to the Incident or Change record. 

    I'm assuming that your goal was to allow for end users to have a more comprehensive form to fill out on the Change submission. You'll need to rely on the Process Fields on the Catalog Item level to provide the submitter with more options.

    I hope this helps!

  • If I understand what you're saying and the process involved correctly, while both Portal-only and Platform users may use the Change Catalog to select request items for maintenance windows to perform change actions, the Service Desk design is for Portal users to only have access to static forms and editable process fields to detail their requests. While Platform users can request the same catalog request item, edit the permanent fields in the request item and detail their request contextually using dynamic forms as if it were an Ad Hoc change, and then submit the request. The limitation for Portal-only users is that they have no access to create Ad Hoc change requests and thus no access to dynamic forms or customer fields.

    The same information can be obtained in both type of users' requests for maintenance windows. However, using at least two separate change request catalog items would be the most elegant way I can conceive for working around documenting change requests from users with either access to the Platform or limited to the Portal. My observation is that the product differentiation does not impact the end user, it impacts the change administrator who must now use two methods for processing change activity and the analyst who must review and combine the differing sets of data.

  • You're absolutely correct! A recommended approach is to utilize a Service Request for end user submissions. The Change Admin can then create and attach the relevant Change. This method is advantageous when dealing with two forms/field sets, ensuring a smoother experience for end users through the Service Catalog.

    By employing the Service Catalog and Change modules, end users perceive it as a straightforward request submission, while behind the scenes, you benefit from streamlined documentation and recording. Some users have enhanced this process by implementing Process Integration on the Service Request, automating the creation and pre-population of certain Change details, establishing a seamless connection between the two records (although this requires some API work).

    One of the reasons I favor this method is that it provides requesters with a clear receipt of their submission and leverages Incident statuses, which are more user-friendly. You can also keep users informed with updates on their requests while maintaining Change records for internal use.

    I trust these recommendations prove helpful. Please feel free to share your thoughts!

  • The difficulty that I'm running into is that in my organization, we don't want both the change requestor and the change administrator to each have to key in the same information into redundant documents. We have no use for dynamic forms on the Change Admin side, but the end-users/requestors providing the details need to know what the change admins are requiring.

  • Understood! 

    If that's the case, then focus on created the mandatory fields in the "Process Fields" section of the Change Catalog. I hope this helps!

  • Hi   So I think the issue you are running into is two things:

    1. Service catalog items and change catalog items do not support using custom forms, yet. 
    2. The change catalog does not support field logic like we support on the service catalog items.

    For number one, we have longer term plans to allow you to use the custom forms on both service and change catalog items. This will allow you to reuse the same form over multiple items. 

    For number two, we have more near term plans to allow you to use field logic on the change catalog items. When we do this, you will use custom fields on the change catalog, instead of process fields, and that will also allow you to use field logic. 

    If you absolutely need the ability to have field logic on your forms, then I would go the way that  recommended with having a service request that collects the information and then creates the change record from there. 

  • This seems like it'll be the best way forward. We were hoping to leverage the dynamic forms in our context to have fewer ticket types. Instead we will try to better categorize our catalogs.