Dynamic content for Connection under Semantic Model Refresh activity

I want to add strong support to this idea, but I'd also like to reframe it: this is a product bug, not just a missing feature. The behavior as it stands is incorrect for any CI/CD workflow, and it has real production risk. The problem: When a Fabric pipeline containing a Semantic Model Refresh activity is deployed from DEV to a higher environment (TEST, PROD) via Git/DevOps integration, the workspace and semantic model target baked into the activity do not remap to the target environment's equivalents. The pipeline silently continues to point at - and refresh - the DEV semantic model, even when running in a TEST or PROD workspace. There is no warning, no deployment-time error, and no indication that the connection is stale or environment-mismatched. Why this is a bug and not just a missing enhancement: Every other Fabric item type that references environment-specific resources is expected to be remapped via deployment pipelines or parameter substitution. The Semantic Model Refresh activity uniquely hard-codes its target by storing a fixed workspace ID and dataset ID at configuration time, with no mechanism for the platform to resolve the correct target after promotion. This violates the fundamental contract of Fabric's own deployment pipeline and Git integration model: that items promoted between environments should operate against resources in that environment, not the source. The consequence isn't just inconvenience - it's a correctness failure. A PROD pipeline completing "successfully" while actually refreshing a DEV model gives false confidence, leaves PROD reports stale, and can go undetected for extended periods. What the fix should look like: At minimum, the activity should support parameterization of workspaceId and datasetId (as suggested by Toanphung) so that deployment pipeline rules or variable substitution can inject the correct values per environment - consistent with how other parameterized activities behave. Note that dynamic expressions are allowed but the changes do not save when exiting the pipeline - indicating there is clearly a bug in the feature. Ideally, the platform should resolve these references relative to the workspace the pipeline is running in, not where it was originally configured, as a default behavior. A deployment-time warning or validation error when a cross-workspace reference is detected would also be a meaningful interim step. There are already a couple of known workaround in the community - using a Web activity against the Power BI REST API with workspaceId passed as a pipeline parameter or overwriting the workspaceId and datasetId in the Aure DevOps deployment pipeline but the fact that users must abandon the native activity to get correct behavior in a multi-environment setup is a clear signal that the native activity is incomplete or broken. Please prioritize this as a bug fix, not a backlog idea. Fabric's value proposition is deeply tied to enterprise-grade CI/CD and ALM. A core pipeline activity that cannot safely survive promotion between environments undermines that entirely.