[FEATURE] Rewire item dependencies when importing multiple items

[iampeterdaniels]

Use Case / Problem

When considering using Fabric CLI to deploy fabric items to one or more workspaces, especially in the case of a new tenant or new environment, we might have multiple items that depend on one another. For example, a data pipeline that runs another data pipeline or runs a notebook. Currently, we have to deploy items in dependency order and adjust references (GUIDs for items and workspaces) and update/redeploy.

Proposed Solution

Could we consider improving fab import so that it handles rewiring dependencies when "importing" multiple items?

Alternatives Considered

import items in order and adjust the referenced GUIDs

Impact Assessment

• This would help me personally
• This would help my team/organization
• This would help the broader fabric-cli community
• This aligns with Microsoft Fabric roadmap items

Implementation Attestation

• I understand this feature should maintain backward compatibility with existing commands
• I confirm this feature request does not introduce performance regressions for existing workflows
• I acknowledge that new features must follow fabric-cli's established patterns and conventions

Implementation Notes

No response

[HasanAboShally]

Hi @iampeterdaniels,

Thanks for opening this issue! you're spot on with this request.

We're actively working on enabling bulk import and export capabilities within the CLI. This functionality is coming soon and will allow you to work with multiple items at once.

Additionally, we're working on an integration with the Fabric CI/CD library and plan to introduce a deploy command directly from within the CLI. This command would handle the rewrites, rebinding, and connecting items across environments — essentially automating the dependency rewiring you're describing.

We're still finalizing some details around the overlap between the bulk import functionality and the deploy command, and I'd love to get your perspective:

If we provide a deploy command that handles rewrites, rebinding, and connecting items automatically, would you still see value in having a more traditional bulk import that imports items individually (item-by-item)?

Understanding your workflow and use case here would really help us shape these features in the most useful way. Looking forward to your thoughts!

[HasanAboShally]

/triaged

[microsoft-github-policy-service]

Triage has been completed for this issue.

[iampeterdaniels]

That's great news! I love that you're also looking at fabric-cicd integration as there is def some overlap in concepts and capabilities.

To answer your question, I think the "deploy" would be sufficient, but would be nice if it was smart enough to not re-deploy everything. The immediate use case is for delivering ETL frameworks to clients. We may dynamically build some of the items based on client input/spec, so we can't rely on just a static item collection.

[iampeterdaniels]

I may be waffling here a bit...it might be nice to have both a deploy and bulk import. Kinda depends on what might be different in their capabilities. I don't want to always deploy all items. I can also envision multiple workspaces as targets, but don't want to overcomplicate things too much.

[HasanAboShally]

Hi @iampeterdaniels,

Thanks for the thoughtful follow-up — this is exactly the kind of feedback that helps us shape these features!

A few thoughts on your points:

On balancing feature richness vs. simplicity:
One thing we're mindful of is keeping the CLI compact and composable. For example, deploying to multiple workspaces should be easily achievable via a simple loop/iteration once the deploy command is in place. So I think we don't necessarily need to build multi-workspace targeting into the command itself. This keeps the CLI flexible without bloating it.

On "not re-deploying everything":
This is a great point, and I'd love to understand your expectations better. When you say you'd want the deploy to be smart enough to not re-deploy everything, are you thinking:

• Explicit selection — you specify which items to deploy (e.g., fab deploy ./items --include pipeline1,notebook2)
• Automatic change detection — the command somehow knows which items have changed and only deploys those

The second option starts to overlap with CI/CD and git-based workflows (which is where the Fabric CI/CD library integration comes in). Curious what you'd expect here for your ETL framework delivery scenario.

On deploy vs. bulk import:
What differences in capabilities would you envision between the two? For instance:

• deploy → handles rebinding, connections, environment-aware
• bulk import → straightforward item-by-item import without the "smart" rewiring

Would love to hear how you'd see these fitting into your workflow!