In Review

Ability for Attachment in Productivity Management to be promoted to DAM at end of Workflow as finalized/clean DAM Asset

Philip Negus 1 year ago in Productivity Management updated by Eric Teitsma 5 months ago 2

Business use case is a workflow is used to facilitate Compliance/Product reviews with sensitive annotations should not live with asset in the DAM. Workflow needs to be setup so the attachment being reviewed/revised lives within the workflow and promoted when finalized. Currently, the only option is to re-upload the final version into a DAM upload line. An automatic promotion would be preferred to limit/control user error in uploading the correct asset to the DAM

In Review

I would like to understand this better.  Annotations do not "live" in the DAM.  They are linked to the project and can only be viewed by a user that can get to the document through the project.  A general user in the DAM would never see annotations that were made on an asset during its development/creation.

Our recommendation is that these files are loaded into the DAM initially as an asset but placed in a WIP classification that limits their visibility.  They are never attachments in the first place.  The promotion of them is to move them out of the WIP classification and into the generally available classifications once it is approved.

We are working right now on a feature to allow you to "duplicate" an Asset in a workflow.  When you do this the duplicate will take only the latest version of the original asset.  All the metadata will be copied and the duplicate will be linked to the original.

So using this a customer could keep the initial asset that has all the versions to get it approved as just a source file and keep it in the WIP classifications or another classification but then move the duplicate which only has the "clean" latest version into the general usage classifications for consumption.

This would be more preferred because by putting these files into the system as Assets right away gives you all the other benefits that the DAM can provide over an attachment. Items like dynamically create additional files that can be annotated.  I.e. Upload a word document and the DAM creates a PDF of it to use in reviews.  Upload a .MOV file and the DAM automatically creates an MP4 version that can annotated, etc.

Or the ability to leverage the Desktop and InDesign connectors to seamlessly check out the files, make changes and check back in.

We still see a use case for Attachments but it should be for project files that will NEVER belong in the DAM.  Like the creative brief, a vendor price list, email targeting criteria, etc.

Assets should be used for all files that will end up being available in the DAM once approved.

Hopefully this made sense but it might have been hard to follow so I am happy to have a call to discuss as well.

In Red Hat's use case: We have a requestor provide activity attachments on the Work Request form and/or tasks. Downstream when we are ready for those files to be uploaded to the DAM - we need to introduce another person to download the files then upload them as assets which by default sets the Creator to someone not technically the "creator". 

In addition, we are attempting to take advantage of the DAM capabilities to auto classify assets based on a User Record. For us we need this based off of the person originally responsible for providing the activity attachments and NOT the person having to upload these files as assets.

Ex: Alyssa is a requestor and provides Attachments 1, 2 and 3 for review/approval and creation. Sally is then playing the "librarian" who will take those final attachments 1, 2 & 3 and upload them via a task as Aprimo assets 1, 2 & 3. Now Sally's name gets flagged as the Creator of all 3. We want Alyssa's name to be identified on these assets. To do so - we have to map yet another field of 'PM Content Requestor Name' (custom field) to match the actual Requestor Name (alyssa) and then create a rule to look at that Requestor name to then drive auto classification.  

The problem is: this value of "PM Content Requestor Name" remains empty while Sally is uploading the asset on to her task because the mapping of values has not yet occurred via the status action.