Start Delivery

• When qualified people request the service

  Allow people to request the service manually. This is useful for services that do not need to be delivered as soon as someone qualifies, but are delivered on request. For example, if a new Marketing employee is hired, this person may need a laptop on the first working day, whereas access to desktop publishing software can probably wait until a request is made.

  If you select this option, also select what happens when users request the service in the Web Portal:

  • Specify the default behavior of at Setup > Behavior.
  • Select Add to cart to add the service to a shopping cart when people request the service.

  You can configure the default behavior for services using this trigger at Setup > General, using the Web Portal Service Request setting.

• When people qualify

  Trigger delivery of the service to all people who qualify. This is useful for services that need to be delivered as soon as someone qualifies. For example, if someone is promoted to manager, you may want certain services to which this person is now entitled to be delivered immediately.

  • Skip delivery for currently qualified people (only available when you configure a new or a duplicated service)

    Trigger delivery of the service only for people who become qualified at a later stage, not who currently qualify.
    This is useful in services that provide people with something that has already been provided to people who currently qualify, for example a service that creates a user in Active Directory or delivers a laptop.

  • Only for newly qualified people (only available when you edit an existing service)

    Trigger delivery of the service for people who newly qualify, for example as a result of changes to qualification settings.
    Clear the option to deprovision the service for all subscribers. It is then delivered to all people who qualify, regardless of whether they qualified before or newly qualify.
    When the service has been delivered, the option is automatically selected again, to prevent reprovisioning of the service each time you make changes to the settings of the service and save them.

• At specific time

  Trigger delivery of the service for people who qualify, at the specified datetime (UTC).
  This trigger does not support multiple service deliveries: if a person is already subscribed to the service, it will not be delivered.

  • Use people attribute

    Select this option if you want to use a people attribute of type Text to specify the datetime (UTC) for delivery of the service.
    Format of the datetime must be YYYY-MM-DD HH:NN
    Example: 2018-06-25 13:25
    

  • Recurrence

    Select this option to create a schedule for recurring automatic provisioning of the service.
    Remember to also configure an auto deprovisioning return trigger, for example As soon as service has been delivered. Recurrence does not work if a person is already subscribed to the service.

The Transaction Safeguard can be used for auto provisioning delivery triggers.

A service can only be reprovisioned for users who are still subscribed to it. If the service was returned, reprovisioning will not occur.

• When subscribers still qualify after organizational change

  Trigger the return and delivery of the service if the qualification of a subscriber changes.
  This is useful when a service needs to be reprovisioned e.g. because the new department uses different Organizational Attributes.

  • If the service was delivered to the user multiple times, it is reprovisioned once for every instance that was deprovisioned/unassigned as a result of the organizational change.
  • The Transaction Safeguard can be used for reprovisioning. In this case transactions from the return trigger (leading to reprovisioning) will trigger the safeguard. This prevents the scenario where deprovisioning is allowed by the safeguard, but reprovisioning is not.

• Skip return workflow (no deprovisioning)

  Reprovision the service as described above, but without the return workflow.
  This is useful if it does not need to be executed, because the delivery workflow immediately reverses this anyway. For example, if the delivery workflow installs software and the return workflow uninstalls it, this may speed up the reprovisioning process.

Starting with Identity Director 2021.2, only people attributes of type text can be used as delivery triggers.

• When the following (combination of) person attributes of type text of a qualified person have changed

  Trigger the delivery of the service when a person attribute or combination of person attributes changes.
  The value of the added person attribute changes when:

  • you manually change the value of one of the selected person attributes on the People page of a person, at People.
  • you synchronize a data connection, at Data Model > Data Connections.
  • a Set Person Attributes and Identifier workflow action in a service overwrites the value of one of the selected person attributes.
    When a list service attribute is used to set the values of a people attribute with Add or Overwrite. As the people attribute is of type text, only the default selected value or the value previously set in a Provide Information workflow action is used.
  • you make changes to the value of a person attribute at Data Model > People Attributes.
    Here, you can view which people attributes trigger a service delivery . This is useful information if you want to delete a specific people attribute.

  The Transaction Safeguard can be used for people attribute delivery triggers.

  Using multiple people attributes of type text as triggers

  • AND / OR

    Insert OR to separate single or grouped person attributes.
    Person attributes that are not separated by OR are processed as a group (displayed as AND in the Preview).

  • Meeting multiple conditions = multiple deliveries

    If you configure multiple people attributes as triggers, each single attribute or group of attributes can be considered a condition.
    If multiple conditions are met, the service is delivered multiple times.

    Example

    Configuration:
    Attribute A OR (attribute B AND attribute C)

    • If attribute A changes, this meets the first condition. Therefore the service is delivered.
    • If attribute B and attribute C change, this meets the second condition. Therefore the service is delivered.
    • If attributes A, B and C change, this meets the first condition and the second condition. Therefore the service is delivered twice.

  • Keeping track of groups of people attributes

    Identity Director uses (invisible) counters to keep track of changes in the attributes.
    Once the counters for all attributes in a group are larger than zero, the service is delivered.
    The counters are reset:

    • when the service is delivered.
    • when a change to the service is saved, that raises the version of the service.
    The counters are not reset when delivery of the service is started by a trigger other than People attribute, for example Reprovisioning.
    Example

    Configuration:
    Attribute A OR (attribute B AND attribute C)
    
    The following actions occur in this order:

    1. Attribute B changes.
       Effect: The counter for attribute B is increased, but the service is not delivered: attribute C has not changed.
    2. Attribute A changes.
       Effect: The service is delivered and the counters are reset.
    3. Attribute C changes.
       Effect: The counter for attribute C is increased, but the service is not delivered: the counter for attribute B was reset in step two.
    4. Attribute B changes.
       Effect: The counter for attribute B is increased. The service is delivered and the counters are reset again.
       

  When you create a Building Block, the people attribute is included.