Global requests management

🤦 🤦 🤦 Combodo's customers only 😎 😎 😎

🚧 Work in progress

Managing complex processes, like onboarding a new employee or offboarding a subcontractor, can be tedious and prone to mistakes. It often requires multiple actions from different teams, leading to issues such as forgotten steps, improper sequencing, or repetitive data entry.

This extension transforms these processes by automating and streamlining them, saving time and ensuring everything is handled correctly.

Key Benefits:

• One-Step Requests:
  • Create a single “Global Demand” (e.g., onboarding) with essential details entered once.

• Automatic Task Creation:
  • Instantly generate all required tasks (e.g., ordering equipment, access badges).
  • Customize actions as needed.

• Effortless Tracking:
  • Monitor progress for individual tasks while the main request auto-closes once all are complete.

• Built-In Oversight:
  • Includes approval workflows and prioritization to ensure accuracy and accountability.

• Fully Customizable:
  • Adaptable for hiring, departures, or any complex process your business needs.

• Requires Approval Process Automation, Customized request forms and Dispatch User Request to a team,
• As a result, it is not compatible with the iTop Essential product.
• Global Request can only be created in a Portal, not in the console.
• A given service subcategory can only be linked to one direct parent subcategory of higher priority. When a subcategory has a parent, if it is selected, its parent subcategory is automatically included, even if not part of the “Global Demand Type”, assuming it is visible by the user.

• Attachements can be added :
  • on global request on creation and latter
  • on user request during global request creation if at least one of the user request has a request template
  • on individual user request after their creation
• Autoclose of global request when all its user requests are closed can only be done if your lifecycle end with a standard close status.
• On iTop 2.7.12, 3.1.3 and 3.2.1, if your PHP configuration is set to display warnings (e.g. for test environnment), you won't be able to create a Global Request (an error will be displayed).

Requires at least iTop 2.4.0. and iTop 3.2.0 for global request 1.5.0 and upward

Use the Standard installation process for this extension.

Ticket::

public function DBUpdate()
{
        $this->WaitForPriorityRequest();
        if (count($this->ListChanges()) > 0 ) {
              parent::DBUpdate();
        }
        $this->ProceedPendingPriority();
}

The following settings are available to configure the module:

The following standard settings might be of interest when setting up the approval feature:

• email_asynchronous
• email_transport

In the end-user portal, creation of a global request is possible through the GlobalRequestBrick. One instance of the brick is added to the standard portal by default with the ID new-global-request. The brick is based on the CreateBrick so it has the same parameters (see here) plus some specific ones:

First, the administrator must define the types of Global Requests portal users can create by adding new Global Request Types. By default, it can be done by:

• the Typology configuration menu under Data administration
• the Global Request menu.

There is 3 kind of GRType that can be created for your users:

• Arrival
• Departure
• Generic

Each of those will allow users to create a different kind of global request with differents inputs. For each of these you can create as many GRType as you want.

Users can add:

Specific data that your user can set:

• For a known beneficiary:
  • a person
• For an unknown beneficiray
  • a name
  • a first name
  • a person as their manager
• An expected arrival date ➡️ mandatory

Specific data that your user can set:

• A known person as a beneficiary ➡️ mandatory
• An expected departure date ➡️ mandatory

Specific data that your user can set:

• A known person as a beneficiary ➡️ mandatory

(*) Technically Service Subcategories are not mandatory, but a Global Demand Type without any is useless, as no Global Demand of this type can be ordered in the portal in that case.

(*) By default, only service request subcategories are displayed as usable in global request type. This can be changed.

Since 1.6.0, we can automate more thanks to a dependency system:

• user request can ben pending until one or more prerequisites user request are done
• unique ranks are asigned to individual user request and checks are performed by itop
• no dependency loop is allowed

The different user requests created under the same global request, use this service subcategory hierarchy for processing parent first, and starting the children only when the parent is resolved. Example if, for instance, the “New DNS name” subcategory has the “New IP Address” as a parent, then, the user request for the “new IP address” will need to be resolved before the user request for the “new DNS name” can be processed.

The Parent Service Subcategory attribute can of course be left empty.

A service subcategory can be used for different Global Request Types.

This class of tickets is, as well, modified by the Global Request extension.

A few attributes are modified or added…:

… and the life cycle has been adjusted accordingly:

The 3 new status have been inserted at the beginning of the standard life cycle of a User Request.

• Waiting for Global Request approval: Pending the approval of its parent Global Request,
• Pending priority request (GR): Pending the resolution of a UR with higher priority,
• Cancelled … if the Global Request has not been approved.

A specific approval process has been created for the Global Requests. Like the standard Extended Approval Scheme this one relies on the Base Approval module.

Please, refer to the Approval process automation documentation if required.

A Global Request can only be created from the portal. For that purpose, the extension brings 2 additional bricks to the standard portal:

• One to handle the creation process
• Another one to list and update the ongoing requests

At creation time, the user is required to select a Global Request type among the ones available.

Once selected, he fills the different attributes related to the request and selects the service subcategories to be created and processed as part of this global demand.

When the user submits the request, iTop will check first that no customized request form (request template) needs to be filled. If this is the case, then a page is displayed where the user can fill its choices.

Pressing the “Submit” button will create the global request and all associated (unitary) user requests.

The newly created global request will then follow its life cycle.

During the life cycle of a global request, the requester can update its public log in order to provide further information to the support agent in charge of the request. He may as well change the list of contacts and add an attachment. The global request is automatically closed when all individual requests are closed.

Once created, the individual user requests will follow their own life cycle. However, a user request linked to a parent user request of higher priority will wait in the status 'pending priority' that the parent ticket is resolved before following its own cycle (approval process, dispatch, assignment…).

Global Requests are managed from the console where a dedicated menu group, including an overview, is added by the extension:

The search and open menus, below the Overview, handle global requests, regardless their final class…

… where the Shortcuts menus look after each individual final class of global requests.

The “waiting for approval” menu lists all global requests that are pending for an approval. Should that be necessary, an administrator (or any profile that have the appropriate rights) may bypass the approval process for a request, from that menu, and that way, move the global request directly in the state “work in progress”.

Q: When should I use “Global request management” instead of “Catalog of procedures”?
A: Both offer to automatically create sub-objects with dependencies, based on a predefined template, but with “Global request management” you can:

• pick and choose the sub-objects to create (by selecting the service-subcategories) during Global Request creation
• define complex sub-objects, thanks to “Customized request forms”
• track SLA on each sub-object
• manage approval on the sub-object level

Q: How Global Request extension work if one of my “Global Request Type” Service/Service Subcategory is not link to my Customer Contract ?
A:

1. If your Service Subcategory has no Parent service subcategory, this Service Subcategory won't be proposed in the Service subcategory of your Global Request. The regarding UserRequest won't be created.
2. If your Service Subcategory has a Parent service subcategory which is linked to your Customer Contract, the regarding UserRequest will be created if you choose The Parent service subcategory.

Q: What happen if a manually suppress a User Request part of a Global Demand?
A: If another User Request within the Global Demand was waiting for the resolution of the delete one, then it will wait forever, and can only be deleted also.

Q: Who can create Global Request in the Portal?
A: Any Portal user can create a Global request in the Portal by default. This can be changed by customizing the Portal.

Q: Can I create a Global Request in the Console?
A: No. Also there are means to create a Global Request object in the console, it will not propose any service sub-categories and won't create any associated User requests, so it should not be done.

Q: Can I clone a Global Request in the Console with an object copier action?
A: No. For similar reasons as for the above question.

Q: Can I csv import Global Requests?
A: No. For similar reasons as for the above question.

Q: What happen if during the GRType creation, we put a circular reference in the service subcategory dependency?
A: Such situation is not checked. To prevent it, you can change the type of the field parent_servicesubcategory_id from ExternalKey into HierarchicalKey.

Q: Creation of Global Demand in the portal fails with error: “Twig content not allowed in this context!”
A: This is due to a security fix brought by iTop 2.7.6. In order to fix this just add this config parameter

Configuration file

$MyModuleSettings = array(
  'itop-portal' => array(
    'enable_formmanager_content_check' => false,
  )

In 2.7.7, this bug is fixed, and this param is removed

Q: How can I choose/force Impact and/or Urgency for UserRequest automatically created by a Global Request?
A: UserRequest are created with default parameters for Impact and Urgency. If you want to force Impact and/or Urgency, you need to add two items in globalrequest-to-unitaryrequest <action_rules> in your Portal Design. These new values will be set for all UserRequests created by a Global Request.

itop-design / module_designs

<module_design id="itop-portal" _delta="must_exist">
      <action_rules>
        <action_rule id="globalrequest-to-unitaryrequest" _delta="redefine">
          <source_class>GlobalRequest</source_class>
          <presets>
            <preset id="1">set(origin, portal)</preset>
            <preset id="2">set(impact, 1)</preset>
            <preset id="3">set(urgency, 1)</preset>
          </presets>
        </action_rule>
      </action_rules>
</module_design>

Q: Can I propose a mean to my Portal users, to create Global Requests or User Request in a single menu?
A: With iTop 2.7, there is an option, with a BrowseBrick, displaying GRType and below Service sub-category. The top level would create a GlobalRequest, while the level below would create a simple UserRequest. Note that this cannot include Incident, will maybe propose the same service subcategory multiple times and will not propose service subcategories which would not be part of a GRType.

Q: Is there any dependency between the Global Request & associated UserRequest caselogs?
A: Out of the box, no. You may put some using standard customization in the ITSM Designer if you have PHP developer privilege.

Q: Can I use the CreationBrick for creating Global Request?
A: No, you have to use the Brick brought by the extension.