Forum Discussion
Copy activity dynamically populated additional columns error when using Expression values
Hi patto_uon ,
Thanks for the clarification. To confirm, expressions such as @{formatDateTime(utcNow())} are only evaluated when they are authored directly inside the pipeline. When the same string comes from external metadata, Fabric treats it as normal text, which is why you see the expression printed instead of the evaluated value.
So when I mentioned a “pipeline-ready expression format,” it meant that your metadata should contain the information needed to build a valid expression, but the pipeline still needs to convert that metadata into an actual expression before passing it to the Copy activity. Currently, the service cannot execute expressions coming directly from metadata files.
To achieve a metadata-driven approach, a small preprocessing step in the pipeline is required to translate metadata into real expressions.
Thank you.
Hi patto_uon ,
Thanks for the update. The behavior you’re seeing is expected.
The Copy Data activity currently does not support evaluating expression objects that use the "type": "Expression" structure when they are provided through external metadata. When this JSON is passed into the activity, it is treated as a standard object rather than a pipeline expression, which leads to the conversion error you are encountering.
In Fabric Data Factory, additional column values must be provided as string-based expressions in the @{...} format (for example, @{formatDateTime(utcNow())}), as these are the only expressions the activity can evaluate at runtime. This is why it works when authored directly in a Set Variable activity but fails when the same expression is nested inside metadata using "type": "Expression".
If you need to maintain a metadata-driven pattern, you have two options:
- Pre-process the metadata before assigning it to the Copy activity and convert any "type": "Expression" entries into Fabric-compatible string expressions (for example, "@{formatDateTime(utcNow())}").
- Update the metadata format so engineers store expressions directly in the pipeline-ready expression format rather than using the “typed expression” structure.
Currently, the service does not evaluate typed expressions coming from external JSON automatically, so one of the above approaches will be required to ensure compatibility with the Copy activity.
Thank you.