Dify’s November 4, 2026 release lets teams package an AI app together with the reusable workflows it calls. For automation teams and consultants moving work into a production or client workspace, this addresses a specific handoff problem: earlier exports could retain tool references without bringing the called workflows along. The feature’s implementation describes that gap.
A Workflow Tool is a reusable workflow that another app can call. The package carries the called workflows at the published versions their tools are bound to, including further workflows those tools call. That is how the 1.19.0 exporter collects the dependencies; it does not simply take each workflow’s latest draft.
The useful scope is a transfer between compatible Dify workspaces, not a move to another automation platform. Use the following sequence to check what can travel and what the receiving team must supply.
1. Check the receiving workspace first
Confirm that the destination accepts the new App package format. All new App packages use format v2, even when they contain no Workflow Tools. Older importers may reject them; Dify 1.19.0 still accepts legacy v1 packages.
For self-hosted installations, treat any platform upgrade as a separate administrator task. Follow the full release upgrade guide before attempting the transfer. The public release is confirmed, but rollout of this feature to every Dify Cloud workspace is not. Cloud teams should verify availability in their own workspace.
2. Check the dependencies, permissions and space
List the workflows the app calls, including those called by other workflows. Then check three things:
Can the sender export each workflow? The exporter’s permission checks leave unauthorized workflows as references and do not follow their downstream dependencies through that excluded branch. Unavailable tools also remain references. A successfully created archive therefore does not prove that every dependency is included.
Can the recipient create tools? Creating missing Workflow Tools requires tool-management permission: owner/admin access without role-based access control, or the relevant permission when that system is enabled. Ordinary app-editing access alone may not suffice.
Is the bundle within the configured limit? The default is 20 bundled Workflow Tool workflows, including nested dependencies. This is a configurable package limit, not a subscription allowance.
Count app capacity separately. The import planner counts each missing workflow app plus the main app if it is being created. The subscription-quota check applies to Cloud deployments; it is not a universal self-hosted app cap.
Illustrative calculation: one new main app plus five missing workflow apps needs six free app slots: 1 + 5 = 6. Dify’s free Sandbox plan lists five apps in total, so even an empty Sandbox workspace would be too small for that example, assuming this package flow is available there. Reused tools do not need new app slots.
3. Export the intended version as a package
In the app menu, choose Export App and keep the .ifpkg package. For Workflow and Chatflow apps, the normal export takes the current draft, including unpublished changes. Dify documents published-version exports through version history on Professional and Team.
Choose the package when the called workflows must travel. Explicit YAML export remains supported, but it excludes bundled Workflow Tool dependencies. Extracting the package’s app.yaml file is not an equivalent way to transfer the whole bundle.
Leave secret values out and configure them at the destination. If included, Secret-type environment values are readable plaintext in the package; exports from version history omit them. Dify’s export documentation also excludes knowledge bases, model and tool credentials, API keys and logs. Arrange those destination resources separately.
4. Import and inspect what was created
To create a separate app, choose Create → Import App in Studio. For an existing Workflow or Chatflow, Import App replaces its draft while preserving its URL and API keys. Imported web-app branding and settings can change immediately, before the new draft is published.
The bundle importer creates and publishes missing child workflows, registers them as tools, redirects the app’s references, then imports the calling app. Child publication can validate destination resources such as knowledge bases. Prepare those resources before import; do not assume everything waits for the main app’s eventual publication.
Reuse is based on tool provider IDs in the destination workspace, not names. Missing tools receive new IDs, and conflicting names get numeric suffixes. The practical implication is that repeating a handoff is not necessarily an update to a same-named tool. Inspect the destination identities before treating it as one.
Read all import warnings and inspect the resulting workflows. The import code allows completion with warnings. If a bundled import fails, it attempts to remove newly created child apps, but cleanup itself can fail. Check for leftovers before retrying rather than assuming a complete rollback.
5. Verify the destination before handing it over
Reconnect the required resources and resolve remaining tool references. Run representative inputs through the main app and its called workflows in the destination, checking outputs and external connections before deciding to publish the main app. An import receipt is evidence that a transfer completed, not that the business process is ready.
The distinction between moving a package and preserving its behavior also appears in RohitAI’s guide to agent-plugin portability. That concerns a different ecosystem; Dify’s handoff still needs its own destination checks.