What should "Import Workflow" do? #6873
eugenegujing
started this conversation in
General
Replies: 1 comment
|
@eugenegujing Please use a sample workflow and screenshots to illustrate the point. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Background
The workspace toolbar has an "Import Workflow" button that loads a workflow JSON file into the currently opened workflow. Its behavior is partly buggy (reported in #6846): besides replacing the canvas content, it fabricates the workflow's metadata from scratch — it sets
widto undefined and renames the workflow to the imported file's name, and it resetsdescriptionand the published state.The
wid: undefinedpart has clear bad consequences. The auto-persist that fires after the import sends no wid to/workflow/persist, so the backend inserts a brand-new workflow: every import silently adds a duplicate workflow to the user's list, and the editor's URL silently switches to that duplicate. Meanwhile the originally opened workflow's shared-editing session was already mutated by the import, so the user ends up with two workflows carrying the imported content — the original (under its old name) and the duplicate (named after the file).Here is an example: Open a workflow A that already has content, then use the workspace toolbar's "Import Workflow" button to import a workflow file B. Two things go wrong: the editor silently navigates to a brand-new workflow created from B (a duplicate entry appears in the workflow list), and workflow A's original content is also totally replaced by B's content. The user ends up with two workflows both holding B's content, and A's original content is gone from A.
Screen.Recording.2026-07-26.at.6.55.22.PM.mov
The question for the community
Fixing the duplicate requires deciding what the import's intended semantics are, and that is a user-facing behavior change, so I would like to hear opinions before finalizing it.
My proposal
Import should replace only the content of the currently opened workflow, and everything else should stay as it is in that workflow: keep its
wid(so auto-persist updates it in place instead of inserting a duplicate), keep its name (no more renaming to the file name), and keep itsdescriptionand published state (today they are silently reset — importing into a published workflow unpublishes it).Concretely, the imported workflow object would be built as
{ ...getWorkflowMetadata(), content: importedContent }instead of a fabricated object. The pre-import content remains recoverable through the version history, since the in-place save records a version like any other edit.In addition, I think a confirmation UI is necessary. Since import directly overwrites the canvas, a user who already has content in the current workflow should see a dialog telling them the existing content will be overwritten by the imported file, and the import should proceed only after they confirm. If the current workflow is empty, the import can proceed without asking. Today there is no warning at all — one click silently destroys the current canvas.
Two consequences worth calling out:
Alternative considered
Make the toolbar import replace the workflow entirely — treat the file as a whole new workflow that takes over, name included. I don't think this is the right direction, because the dashboard upload button already provides exactly that "create a new workflow from a file" feature, and duplicating it inside the workspace would leave no way to import content into an existing workflow.
I have a working fix with unit tests ready following the proposal above (the confirmation dialog could be part of the same PR or a follow-up) and will open a PR referencing this discussion and #6846.
Feedback on the proposal is very welcome.
All reactions