This discussion is archived
6 Replies Latest reply: Feb 10, 2013 6:15 PM by William Phelps RSS

Retention: Dispostion triggers

Bunty Journeyer
Currently Being Moderated
Can we have the disposition Rule with Trigger pointing to latest Revision only? I didn't find any out-of-box feature or couldn't figure out a way to create one in Custom Direct Triggers.
  • 1. Re: Retention: Dispostion triggers
    William Phelps Expert
    Currently Being Moderated
    I would be more comfortable seeing the entire use case before getting too deep. Why do you want to work only the latest revision (since at some point 'every' revision would have been 'the latest', so the rule you want to design would have been evaluated on each item anyway at some point)?

    Also, is UCM with records management enabled, or the full-blown URM, or the adapter between URM/UCM? Your potential options will vary based on which one is being used.
  • 2. Re: Retention: Dispostion triggers
    Bunty Journeyer
    Currently Being Moderated
    UCM with records management enabled!

    use case:
    Dispostion is to be driven by a custom date field (myDateField) which is entered during checkin of content item. The same content item can have a new revision at later point and with a different value for myDateField.
    Now, for the items with (currentDate - myDateField) = x years, Delete the content (all revisions). If the latest revision has not met the x year criteria but, the older revisions meet the criteria, no action should be taken. Record should be present for reference.
  • 3. Re: Retention: Dispostion triggers
    William Phelps Expert
    Currently Being Moderated
    So at what point does the latest revision qualify for disposition if there are no new revisions being added? Does the document just sit around forever?
    Bunty wrote: Dispostion is to be driven by a custom date field (myDateField) which is entered during checkin of content item.
    Bunty wrote: Now, for the items with (currentDate - myDateField) = x years
    So is statement 1 ("Dispostion is to be driven by a custom date field (myDateField) which is entered during checkin of content item.") or statement 2 ("Now, for the items with (currentDate - myDateField) = x years") the correct behavior? These statements are not equivalent. In statement 1, you are saying the custom date is the sole driver. In statement 2, you say a calculation must occur first. You might being getting the disposition "wait" period mixed up with the triggering event. These are two different things, and defined in different parts of the overall disposition.

    BTW, there isn't a way to do statement 2 - a trigger is based on either a date (direct custom trigger) or a boolean (indirect trigger) - not off an integer value per se. You would have to make the trigger based on xCustomDate, but take either dInDate or dCreateDate and add x years to that date and populate xCustomDate with the newly calculated date. In such a scenario, the user would never fill in xCustomDate, but you wouldn't need it anyway. The entire disposition would be really based on the creation date (After created, wait x years, delete).

    You're actually closer to a superseding action than anything else, but that might be getting off base a bit.

    I think the way you'd probably need to do this is to simply have a multi-phase disposition defined. Create a new trigger called "After CustomDate". In the content date field, add xCustomDate. This will cover the latest revision.

    Now when you create the disposition instruction set for the category, click Add.
    - Choose "After Custom Date", wait "x" years, Do Delete All Revisions. (This covers you should the item go dormant, and would kill all old revs.). Click OK.
    - Now click add again. Do not choose "Preceding Action", but select "No Longer Latest Revision". Choose wait 0 weeks, then "No Action". (This will keep the older item in place, as long as xCreateDate for that actual revision (and not the latest one) is later than the date that it was no longer the latest revision. Whew...)

    In a nutshell, for the old revs, the disposition engine will look at xNoLongerLatestRevDate (or something like that, it's a system field) and xCustomDate.
    - Since xNoLongerLatestRevDate should occur before xCustomDate, the "No Action" action is fired, keeping the old revs from going away until the "latest released" item goes away. If you want the older item to go away instead of hanging around, change "No Action" to "Delete Revision".
    -
  • 4. Re: Retention: Dispostion triggers
    Bunty Journeyer
    Currently Being Moderated
    Thanks william..
    My bad, I mixed Trigger and Wait for.

    After: My Custom Date field(MyCustomDate1)
    Wait for: x years from Custom Date field of "*latest revision*".
    Action: ...


    >
    You would have to make the trigger based on xCustomDate, but take either dInDate or dCreateDate and add x years to that date and populate xCustomDate with the newly calculated date. In such a scenario, the user would never fill in xCustomDate, but you wouldn't need it anyway. The entire disposition would be really based on the creation date (After created, wait x years, delete).
    I can't, x is not constant.
    I think the way you'd probably need to do this is to simply have a multi-phase disposition defined. Create a new trigger called "After CustomDate". In the content date field, add xCustomDate. This will cover the latest revision.
    it also covers the revisions that are not latest. Correct me if I am wrong.


    After some thinking I figured (got it from the dDocLastModifiedDate concept)...
    have another custom field (MyCustomDate2) (drives the Dispostion). At check-in MyCustomDate2 is same as MyCustomDate1 but, at the time of new Revision, update all the previous revision MyCustomDate2 with MyCustomDate1.
    This way, the disposition will only be triggered when the latest revision has passed x years from MyCustomDate1
  • 5. Re: Retention: Dispostion triggers
    DMP1970 Newbie
    Currently Being Moderated
    Use the LastNewRecordAdded to fire off only the latest revision.
  • 6. Re: Retention: Dispostion triggers
    William Phelps Expert
    Currently Being Moderated
    Bunty wrote:it also covers the revisions that are not latest. Correct me if I am wrong.
    This is the easiest part of the discussion. In the multiphase scenario I posted earlier, the first event that is satisfied in a category disposition instruction set is the event that is executed. Think of a multiphase instruction set as a series of decision paths. The processing goes down the path of the first event that is satisfied. It doesn't "complete one path, then jump to another path", so setting "No Action" for items that are "not the latest revision" will just sit there until the latest revision of the item (whatever that rev number is) triggers the xCustomDate trigger. The event for xCustomDate is ignored on the older revs, and is technically in force only on the latest revision.

    A simple illustration for category "z" with a multiphase disposition as described earlier.

    - Document 'abc' with a create date of 1/1/2013 has rev 1 with xCustomDate value of 6/1/2013.
    - Document 'abc' with a create date of 3/1/2013 has rev 2 with xCustomDate value of 7/1/2013.

    Since category "z" has one triggering event based on xCustomDate, and another triggering event based on "No Longer Latest Revision", rev 1 would have originally been eligible for disposition (based on xCustomDate) on 6/1.

    However, you checked in rev 2 on 3/1, which now triggers the "No Longer Latest Revision" event for rev 1 on 3/1. Since the "No Longer Latest Revision" event on 3/1 has fired for rev 1, the xCustomDate event for rev 1 is ignored in any subsequent processing. Now, rev 2 would be eligible for disposition on 7/1, and if no further revisions are created, after the xCustomDate event on 7/1, all previous revisions would be removed if the "do" action for the xCustomDate event is "Delete All Revisions".
    Bunty wrote:Wait for: x years from Custom Date field of "latest revision".
    And the multiphase disposition setup I described earlier behaves in exactly that manner. No extra data manipulations needed (or extra hidden/phantom fields). The "latest revision" is subject to the xCustomDate trigger event until a new rev is checked in (UNLESS you fail to check in a new rev PRIOR to the xCustomDate value of the previous rev.) Using the example from earlier, if you were to create rev 3 on 8/1, you would be too late to prevent the action tied to xCustomDate on rev 2.

    It's actually fairly straightforward.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points