Delegated Financial Authority (DFA) enables you to self-manage your Managed VMware spend in CloudCreator. You can control any extra charges that could be incurred when users establish or modify virtual machines.
- DFA Levels
- How DFA Operates
- Operating Without DFA control
- The Progress of a DFA Request
- DFA Request States
The DFA levels are defined as follows:
- Each virtual cloud has its own set of DFA levels.
- Each CloudCreator user has a single DFA level assigned to them.
- Each DFA level has a $$ value.
To add, assign and modify DFA levels, see Add DFA Levels and Assign Users.
DFA operates as follows:
- Each creation or modification of a Managed VMware virtual machine, is contained within a DFA Request (DFA.R).
- Each resource can have a maximum of only one DFA.R in an unapproved or approved state at a time.
- A DFA.R captures both the ‘From’ and ‘To’ states of the resource being created or modified.
- A resource creation has no ‘From’ state, and resource deletion has no ‘To’ state.
- CloudCreator can calculate the ‘per month’ value of both the ‘From’ and ‘To’ state of the resource. The value of the DFA.R is the difference between these two values.
- Users need a DFA level greater than, or equal to the value of the DFA.R, before they can approve it.
- Changes to resources cannot be performed until the DFA.R has been approved in CloudCreator.
If your organisation prefers to operate without the DFA controls, you can assign all users to the DFA level of Unlimited. This means that all changes will be auto-approved and no approval steps will be enforced upon the users of a CloudCreator.
Each DFA Request (DFA.R) will progress from the state of 'Unapproved' through to one of the following final states:
The diagram below shows the possible paths that a DFA.R can progress through. See DFA Request States below to find out more about each stage.
The two most significant states in the flow are:
- Approved or Declined. These states are controlled by the DFA Level and DFA.R value.
- Applied. This state occurs when the changes in the DFA.R have been made. It is only possible when a request has been 'approved'. The ability to apply a DFA.R is controlled by the role(s) an individual user has. In the case of VMware, the user needs to have a VM Admin or equivalent role.
The following table describes the possible DFA Request (DFA.R) states.
The VM the DFA.R describes can't be modified. A resource can only have one DFA.R in progress at a time. This reduces the likelihood of a VM being modified while a DFA.R is already in operation.
If a VMware user needs to modify a VM which already has a DFA.R in place, they can view all the details. They cannot create a new DFA.R but can contact the originator to resolve the issue of two concurrent changes being attempted.
A DFA.R can be cancelled in the following situations:
When a cancellation occurs, an email notification is sent to the originator if the DFA.R, unless it is the user who performed the cancellation. The DFA.R information is retained so the originator can track what happened to the DFA.R, and recreate it if needed.
|Approved and Applying||
When a DFA.R has been approved, the VM it relates to can be modified.
‘Applying a DFA.R’ is the task of making the change to the VM managed by the DFA.R. As the term ‘action’ is already used in relation to VMs, the term ‘apply’ is used instead.
The application of a DFA.R is performed by the originator (or another user with a Managed VMware role or sufficient rights). They are assumed to be competent to decide whether a VM restart is OK, and should be part of the change that needs to be applied, ie: they have the technical knowledge to make that decision.
|Applied||The VM modification managed by the DFA.R has been completed.|
Occurs when a change occurs to a VM outside of the control of CloudCreator.
A stale DFA.R is expected to be an exceptional circumstance. In CloudCreator, the following events occur: