Lets not merge this with the big wizard Idea. I am already having internal conversations to figure out if and how we want to specifically support this Close document wish.
Some input from the internal Teams chat (disclaimer: did a quick “Translate from Dutch and professionalize” prompt to Claude):
Implementing “close document” as an initiating action would contradict the original design philosophy of the process action framework. The concern lies in triggering logic based on closing a document whose opening context is unknown. Specifically, if a document is already open before the process flow initiates, we lack visibility into how, why, or when it was opened. Attaching process logic to its closure could inadvertently disrupt the user’s workflow by triggering unintended actions.
This consideration led to the original design decision that “close document” actions should only apply to documents owned by the process flow itself—documents we can confirm were opened as part of that specific process. Under this constraint, it could not logically serve as an initiating action.
That said, I’m open to reconsidering this approach, and I’m providing this context to inform the decision. There are legitimate use cases for this functionality, particularly with the introduction of modal documents. However, it’s important to note that this change would also enable potentially problematic implementations, and proper usage would be the responsibility of the implementer.
Any thoughts? @Mark_Plaggenborg, @PeterKeeris, @MatteoSangiorgi
@Arie V I understand the warning and that is also the reason I mentioned it comes with a certain responsibility of the developer.
The design philosophy and the implementation don't really seem to match, in my opinion, as the Close Document requires a user to say which table to close and does not even support variant specification. There is a document_id, but that is not mandatory. The action can also be used without the Open Document being part of the flow.
The flexibility of the current implementation is of course why the idea has been made. Even though the Close Document is not a starting point now, we technically use it as such anyway by just working around it to have a task in front of it first. Which technically is just clicking a “Close” but on a different location.
After all that, let’s see if we can make it an option, but perhaps with some restrictions for less risks. Some suggestions and perhaps other users have an input as well.
- Limit the Close Document triggering as starting point only when the Document is not part of a running flow.
- Have the Close Document support Variant specification to limit where it would be uses.
- Only allow it on Modal document (other customers might see this differently perhaps).
- Trigger the flow only when using the clicking of the “Close” button and not through other means.
I am also playing a bit with the idea of having a new entity introduced that can be buttons next to the location where the “Close” button can be found. This could leave the “Close” alone, but still make a process flow possible with its distinct action. It probably needs to be limited to 2-3 buttons maximum perhaps. It would still support what can already be done and the Close Document will be the 2nd action after the button. The people that really want the original “Close” gone, will probably result to custom.css anyway.
I’ll leave it at this for now and see what other people will input for this idea.
