Task Policy Events

A Task’s Policy Event determines when the script will be executed.

For example, if you want to rotate a password every time a user Checks In a record or simply every Friday, then that Check In or Every Friday is the policy event that triggers the password rotation (i.e. the script).

The following is a list of available Policy Events:

• After creating or updating a record – This event is triggered after the applied record is initially created or after it is updated, either by a user or system interaction.
• After creating a record – This event is triggered after the applied record is initially created or imported into the system.
• After Expire – This event is triggered after the approved workflow expires on this record.
• After Session – This event is triggered after an active session on this record is completed. 

  • Check to defer execution to enabled (checked).

    In order to select Check to defer execution until completion of the last active session checkbox first need select After Session checkbox otherwise will be js error on save.

• After Check-In – This event is triggered after the approved workflow is checked in on this record.

  • Check to defer execution until completion of the last active session – When enabled (checked), the event will only trigger when the last active session is completed. This includes all concurrent sessions on this single record or any other record if it is configured to use a Reference Record. In the case of reference records, the logic will check all records that use this reference and only trigger the policy when the last of all possible sessions has completed.

• n minutes after unlock – Enter a numerical value for this event defined in minutes. This event is triggered this many minutes after a record’s secured field is unlocked. For example, 60 minutes after the password field is unlocked, it will be queued for rotation.
• Every nth day of each month – Enter a numerical value for this event defined by the day of the month. This event is triggered on this day each month. For example, the 20th day of every month the password will be queued for rotation.
• Every <selected day> – Select a day of the week. This event is triggered on this selected day every week. For example, every Sunday the password will be queued for rotation.
• On Demand – This task will be made available in the record’s Task menu and can be initiated when needed by an appropriately permission-ed user.
• Every nth day – Enter a numerical value for this event. This event is triggered every n number of days. For example, every 1 day (i.e. everyday), the password will be queued for rotation.
• Every x to y days – Enter a numerical value for the start and end day of this event. This event is triggered on a random day between your two defined values. For example, for every 15 to 30 days, the password will be queued for rotation on a random day between the 15th and 30th day of each interval.