+9
Qualified

Task Upload into DAM - if file then deleted from the same upload task, also remove record from DAM

Richard Heynes 1 year ago in Productivity Management updated by Greg 5 months ago 9

Currently when you upload a file through the Task Inbox into DAM, it will create the record in DAM as expected. However, if you then delete the file from the task....perhaps you uploaded the wrong file for example, the record remains in the DAM.

It would be an improvement if this record in the DAM was also deleted at this point, this would save the user (assuming they have access) going into the DAM, finding the erroneous record and deleting. It would be easy for the user to not be aware or simply forget to do this, resulting in bad data essentially in the DAM.

Workflow Tasks Ingestion / Upload

After reading through the rest of these comments it sounds like at the end of the day all of our use cases come down to workflow and DAM Must be able to stay in sync.

Currently:  The issue remains that the Workflow will send an asset to DAM immediately upon upload.  As soon as this happens the two assets are separate entities and can not be updated together.  This creates a much higher risk of the two environments going out of sync because there is no opportunity for review or oversight. 

In my opinion, adding additional controls to DAM will not solve this.  To Bart's point, the current permissions configuration already provides the means to control who can delete assets if anyone needed to treat a temporary classification like the uploads UI.  To Eric's point, most of us using the workflow to send assets to DAM is likely making use of Rules so as soon as the asset is uploaded to DAM, it should be sent away to a real classification anyway.

Ideal Scenario:  The workflow can be configured to not send an asset to DAM until closing a job specifically tells it to AND any asset in that job remains linked in such a way that if further edits occur in workflow they can be sent to the same asset in DAM.  I am uncertain around the necessity to have any edits in DAM flow back to the workflow, but at the very least if there are major changes, a new task can be started to from DAM as a separate configured edit process.

Additional Comment (added on behalf of  Tom @Chanel) - pending account setup.

"First, our main problem is not the asset deletion in DAM but the fact that users will see the asset in DAM after closing the task.
We did set Status classification and a script for archiving those assets but the problem is that our script will also grab assets uploaded if the task is not closed the same working day as we have no way today to differentiate an asset upload in a task not closed from an asset deleted from a closed task.
We need that delete asset action from MP being able to be tracked and triggered some event enabling us to update values on the DAM side or some automatic action setting the deleted asset as locked on the DAM side."

Hi,
I have additional comments. 
1) Is it not best to consider the "adam-classification-path" only as a temporary location? Every user who is involved in uploading assets (through workflow) will need write access in that classification, but as a consequence will also see all assets that are residing in that classification. This is different to the 'my uploads' principle in DAM, where new uploaded assets are hidden for other users until the uploader explicitly makes them available. In that sense, I would think, one tries to remove that "adam-classification-path" classification as soon as possible after successful upload. E.g. use a workflow status action to classify the asset in the final classifications (e.g. based on extended attribute values) and at the same time unclassify it from the common (temporary) classification. 

2) On the topic of locking assets in DAM. Not sure if this is really needed as a new feature. Aprimo DAM has already a permission setting for asset deletion. So 'lock'-'unlock' principle is not more than classifying an asset in a classification where delete permission is allowed or denied for your user role. At delaware, we discourage our clients to give explicit 'delete' permission in DAM for most users, but guide them to use a custom action or WF to archive assets instead (if needed librarian/admin role can still be configured to have asset delete permission within the archived assets classification).

Coming back to the above scenario: "adam-classification-path": this could be an exception classification where delete permission is granted to upload users. As soon as the asset is unlinked from that classification, it can no longer be deleted by these users. As for workflow (Productivity management), it would be great if the delete action on the Aprimo assets (in PM tasks) is smart enough to take permissions into account and not simply throw an error: e.g. if you do have delete permissions on the underlying DAM asset, it is really deleted. In the other cases, the link is only removed between the activity/project and the underlying DAM asset.

Qualified

We understand the use case.  But my concern is knowing when it is safe to delete it.  I think Bart's suggestion might be a good compromise but that will only work if you do not have any automated rules on the DAM side.  If you have rules setup that once you add an asset into the DAM it is automatically put into a few more classifications then you will be in a spot where you can still never delete the file from the Task.  Bart what is your opinion on this?  How often to do you see that being the case?

Aprimo is also going to add some controls for the opposite flow as well.  A user in the DAM deletes a record that was associated to Task and Project and therefore causing the project to get stuck in some cases.  The current thinking is to add a "lock" feature on records in the DAM.  If a DAM record is "locked" it can only then be deleted by an admin.  So once you add a record to a project it would become locked and could no longer be deleted except by an admin.  The thought is this lock could be exposed to the API and used for other integrations as well as a why to restrict deletion of records being used by another process or system.  However, if we do this work we will need to discuss this use case.  The oops I uploaded the wrong file.  My first thought would be that we wait to "lock" the record in the DAM until the user closes their Task.  This way the user would still have an option to catch it was the wrong file and still delete it as long as they have not yet closed the task.

Thoughts on both these topics?

Hi Eric,
This asset deletion problem is raising up again with Chanel.
First, our main problem is not the asset deletion in DAM but the fact that users will see the asset in DAM after closing the task.
We did set Status classification and a script for archiving those assets but the problem is that our script will also grab assets uploaded if the task is not closed the same working day as we have no way today to differentiate an asset upload in a task not closed from an asset deleted from a closed task.
We need that delete asset action from MP being able to be tracked and triggered some event enabling us to update values on the DAM side or some automatic action setting the deleted asset as locked on the DAM side.

Agree  - this will be also relevant for other customers who use WF/DAM

I have the same request. Alhough I think there should be a safeguard based on the asset classifications: once an asset is classified in any classification other than the "adam-classification-path" (Aprimo System setting), I would no longer delete it from DAM. An asset linked to multiple classifications, is potentially already shared/distributed though DAM. As Richard mentions, the case is really to undo the upload of a wrong file, similar as you would do if you accidently upload the wrong file in the My Uploads section in DAM. 

Chanel - this will be useful for Chanel too.