Currently, Constellation enforces a strict design language where default form action buttons (like Submit) cannot be hidden or disabled. While maintaining a consistent UI across the platform is generally a good practice, certain use cases require more flexibility to prevent poor user experience.
Consider a standard payment screen layout: We have integrated a custom component for a payment gateway, which features its own native Pay button. From a user’s perspective, clicking Pay is the primary, defining action of the screen.
However, because Constellation forces the default Submit button to appear directly underneath the custom component, it creates significant user confusion:
If a user clicks Submit without clicking Pay, it breaks the expected application flow. (Workaround: We can stop the step from being submitted using validations)
If a user successfully clicks Pay, it is counterintuitive and redundant to expect them to click Submit a second time just to advance the assignment. (Workaround: Call finishAssignment API from the component for auto submit). There is also a risk of user clicking Submit when the payment is in progress.
In scenarios where a custom component handles the primary transaction, wouldn’t it be highly beneficial to give developers the capability to hide or conditionally suppress the default form action buttons? I’d love to hear how others are handling this limitation or if this is on the product roadmap.
You can hide the button with your own DX Component (template), although not recommended as a general rule, it is achievable.
Specifically in the DX Component, I don’t know what does this, but you can look at Hierarchical form as tasks as I know this was built to hide the default submit/next and use the hyperlinks to submit instead. @oveni@tscheer@ongf1@RichardMarsot might have some clues?
You’d need to think about this. In your example your component does the payment but at some point you’ll need to submit the assignment. If you go down the custom route, that would have to be something in your custom DX component design to consider.
I agree with @MarcCheong . I would recommend processing the payment when the user clicks Submit, as this makes it easier to handle exception scenarios. For example, what happens if the payment service fails or if incorrect payment information is provided?
The DX component can certainly be used to enhance and improve the UI experience. However, the actual service invocation should remain in the Pega layer so that the service logic is centralized, manageable, and can be extended for other use cases in the future.
I agree that, in general use cases, the actual service invocation should remain in the Pega layer. However, this specific payment integration component operates as a completely self-contained package.
Because the payment method selection, user authentication, and transaction completion are fully handled on the client side by Stripe’s JS SDK—with everything managed directly via their application dashboard—we don’t have the same level of control over the execution lifecycle. This is why we need to handle the flow differently than a standard backend Pega integration.
Thank you for pointing me toward the custom DX component template approach; it gave me the exact insight I needed to find a solution.
However, I did encounter a small hurdle with this approach in Pega Infinity 25.1. The original component logic targeted the very last div in the form container, assuming it held the action buttons. In version 25.1, the DOM structure has slightly shifted, and the action buttons are now located in the second-to-lastdiv.
To make the solution robust and upgrade-safe, I built a custom field component with logic inspired by that layout template. Instead of relying on hardcoded DOM positions, my component dynamically scans the container for the specific div elements containing buttons labeled “Submit” or “Cancel” and hides that exact element.
This approach works flawlessly for me now, and I can easily reuse this field component on any form view where default action buttons need to be suppressed.
As for submitting the assignment: the user doesn’t actually need to interact with a secondary button. Once they click our custom “Pay” button and the transaction is successfully completed via Stripe’s SDK, our payment integration component automatically calls the API to submit the assignment and advance the flow.
Thank you for sharing the details. I was thinking to hide the flow action buttons, but what happens if there are subsequent assignemnts for the user to move forward with the case workflow. We can still do it behind the scenes with background jobs to move forward with the assignment as long as DX component can update the status of the case.
For my implementation, the buttons are only hidden for the specific flow action where the component is configured. Once this assignment is completed and the case moves forward, the default action buttons will display as usual on all subsequent assignments.
