# ApprovalCompositionStrategyType (Complex Type)

### Namespace: http://midpoint.evolveum.com/xml/ns/public/common/common-3

Prescribes how individual approval requirements should be composed into overall approval schema.

Item Summary
Name | Type | Multiplicity | Description
--- | --- | --- | ---
order | property int | [0,1] |
exclusive | property boolean | [0,1] | If set to true, this fragment might be the only one with this particular order number.
mergeable | property boolean | [0,1] | If set to true, this schema fragment is eligible to merging with other fragments of the same order.
mergeIntoOrder | property int | [0,-1] | Which fragments should this one be merged with.
mergeIntoAll | property boolean | [0,1] | Indicates that this fragment is to be merged into all the other "base" fragments.
mergePriority | property int | [0,1] | Provides an information about order in which this fragment is merged (lower numbers are processed before higher ones).
mergeOverwriting | property QName | [0,-1] | If stage B is being merged into existing stage A (i.

- ### Items

  - #### order

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order:

  - #### exclusive

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order:

    If set to true, this fragment might be the only one with this particular order number. (Other fragments could be merged into it, but in "mergeIntoOrder" mode. TODO TODO TODO)

  - #### mergeable

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order:

    If set to true, this schema fragment is eligible to merging with other fragments of the same order. (Non-mergeable fragments with the same order are ordered randomly. Mergeable fragments must have order filled-in.) Mergeable fragments must have "order" attribute set. Restrictions on merging schema fragments: 1) Mergeable fragments must contain exactly one stage. It is merged with the stage(s) of the other fragment(s) without any further considerations (e.g. regarding stage order or name or whatever). 2) It is expected that single policy rule triggered all the fragments that are being merged. So we consider any of these rules.

  - #### mergeIntoOrder

    Flags: RAM,runtime

    Multiplicity: [0,-1]

    Display order:

    Which fragments should this one be merged with. This is mutually exclusive with the "order" attribute. If order is set, it is not possible to specify mergeIntoOrder. Both fragments with the same order are considered "equal". This can be used e.g. to provide a different set of approvers (for the given stage). If mergeIntoOrder is set (usually with multiple values), this fragment is considered as an augmentation of other ones. This can be used e.g. to provide an escalation or notification strategy, custom form information, etc.

  - #### mergeIntoAll

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order:

    Indicates that this fragment is to be merged into all the other "base" fragments. This is mutually exclusive with the "order" and "mergeIntoOrder" attributes.

  - #### mergePriority

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order:

    Provides an information about order in which this fragment is merged (lower numbers are processed before higher ones).

  - #### mergeOverwriting

    Flags: RAM,runtime

    Multiplicity: [0,-1]

    Display order:

    If stage B is being merged into existing stage A (i.e. mergeOrder B is greater mergeOrder A), all non-null values of B will be added to values of A; overwriting them in case of single-valued items. For items marked as "mergeOverwriting", the actual values of B (even those that are null or empty) overwrite those in A.