In this example, the watchfolder shall only contain new files. Ingested files are then moved to another storage. Therefore we add another task "Move File".

This task has again an input parameter "SourcePlatformUri" to which we again assign the global workflow parameter with same name, as this task shall move the originally discovered file to another target storage.
Additionally, it offers an input variable "TargetPlatformUri" which defines the target storage as an abstract Uri to which the file shall be moved. This storage will be defined in the watchfolder creation (see the Watchfolder Creation section) and passed to a global workflow parameter with same name.
To provide this expected global parameter we again assign that parameter with the same name to the local parameter using expression language. To do so, select the local input parameter and assign the global parameter as "#{TargetPlatformUri}".

The task has three more optional parameters that we ignore for now. They can be used to optionally change the name, extension and/or sub path of the original file.
Viewing the "Global Workflow Parameters" one can see the two global input parameters "SourcePlatformUri" and "TargetPlatformUri" as expected for a watchfolder workflow.

Another visible global parameter is the "TargetPlatformUri", which was introduced by the "MoveFileVidispine" task. Selecting that task again one is able to rename this output parameter, e.g. to "MovedFileUri". The task will pass the abstract Uri of the new file (represented by a new file Id) to this parameter. One might ask oneself why there is a new file and file Id for the moved file.
This is due to the logic of the underlying object management. Actually moving a file means copying it and deleting the original file. Thus a new file with new file Id is created. The asset or item will reference this new file finally. Via the output parameter one receives the new file Id for further operations.