Managing Package Requirements

Overview

An RPA journey starts in Studio, the realm of workflows and activities. In designing workflows developers can use various objects, which are typically managed centrally from Orchestrator using folders, which enable you to maintain fine-grained control over your automations and the associated objects.

These objects are essential for a successful process execution. Lacking any of the indicated objects prevents the process from executing successfully.

The Package Requirements tab allows you to identify missing objects and manually add them at the process level. This helps with:

• educating users about process dependencies,
• reducing manual workflow debugging,

• identifying missing objects without the need to switch between Studio and Orchestrator UI.

  
  

  

  
  

Note: This feature is compatible with processes that have been created using Studio version 2021.10 and later, in conjunction with activity packs version 2021.10 and later.

How Package Requirements Work

When you create a process, Orchestrator inspects the underlying package with all its component .xaml files and aggregates their intrinsic objects, such as:

• storage buckets
• assets
• queues
• queue, time, and event triggers
• other processes
• action catalogs
• connections
• business rules

Depending on whether the respective objects are detected or not, there are two Package Requirements tab behaviors:

• Tab turns red - the workflow has some dependencies that are not present in Orchestrator, therefore you need to add them.

• Tab is empty, displaying that "This package version contains no requirements." - the uploaded package does not have any requirements.

  Note: Orchestrator does not automatically detect the requirements for the packages that stored in external feeds.

Package Requirements Statuses

General statuses

• Available - the object is present in Orchestrator. No further action needed.

• Missing - the object is not present in the current folder in Orchestrator. You can either link it or add it into the corresponding Orchestrator folder, provided you have the proper permissions.

• Folder not found - the object supposedly exists in an Orchestrator folder that was referenced in the Folder path field of an activity, but:

  • the folder does not exist in Orchestrator. You should add the folder in Orchestrator, use the same name as indicated in the Folder path column, and assign users to it.

  • you do not have access to that folder. You should ask for access to the Orchestrator folder indicated in the Folder Path column.

• Unknown - the object name could not be determined. No available actions to perform. There are several scenarios which may result in an Unknown status:

  • you do not have the correct permissions set for that type of object;

  • a workflow activity references a queue item, for example, which cannot be linked to its queue.

    Note: The unknown status of an object does not prevent the process from executing successfully.

• Invalid filters - the filters of a connection are unconfigured.

Note: The unknown status of an object does not prevent the process from executing successfully.

Trigger statuses

In addition to the general statuses, triggers display the following statuses:

• Pending creation - adding a trigger requires associating it to an existing process. While the process gets created, the trigger resides in Orchestrator memory and it becomes active after the process creation. You can edit triggers from the package requirements tab while they have this status. Later on, you have the option to edit them from the Triggers page.

• Invalid configuration - the selected runtime is not available.

• Duplicate name - the trigger name is duplicated.

Permissions

To manage package requirements, you need the following permissions:

I want to ...	I need ...	The folder access I need ...
... see the available packages	View permissions on Packages (tenant level)	Not applicable, as Packages permissions are set at tenant level.
... upload a package	Create permissions on Packages (tenant level)	Not applicable, as Packages permissions are set at tenant level.
... see the available objects	View permissions on the specified object	Get access to the folder(s) that contains the object.
... add an object	Create permissions on the specific type of object	Get access to the folder(s) you want to add the object to.
... import an object from a different folder	Create and View permissions on the specific type of object	Get access to: the folder(s) you are importing from, and the folder(s) you are importing the object to.

Managing Missing Objects

For each missing object, except action catalogs and connections, you have the option to add it or to import it in the current folder, provided you have the necessary permissions.

Note: You cannot add action catalogs and connections from the Package Requirements tab in Orchestrator, but from Action Center and Integration Service, respectively.

Adding a Missing Object

Prerequisites: Make sure you have Create permissions on the specific object and access to the folder you want to add the object to.

1. To add a missing object, click the corresponding Add button. The Create [object] page opens.
2. Configure the object as needed.
   The name field is prefilled with the missing object name and cannot be edited. This restriction applies to respect the object name used in the workflow.

Importing a Missing Object

If you suspect the missing object exists in the current tenant, but in a different folder, you can import it into the current folder.

Prerequisites: Make sure your have View and Create permissions on the specific object, and access to both the folder you are importing from, and the folder you are importing the object to.

1. To import an object from a different folder, click the corresponding Import button. The Link [objects] from other folders page opens, displaying two tabs:
2. If the object exists in other folder(s), it appears on the Select [object] tab. Select it.
3. Click Continue to navigate to the Folder validation tab.

   After selecting the object, the Folder validation tab displays the source folder(s) you can import from.

4. If the object exists in multiple folders and you have selected all copies in the previous step, you are now prompted to keep only one source folder.
5. Remove the object copies associated to the folders that you do not need to import from.
6. Click Link to import the object into the folder indicated in the Folder Path column.
7. After adding or importing an object, you are redirected to the Package Requirements tab to continue adding or importing the missing ones. Notice the statuses changed for the objects that have been added or imported.

Important:

In the case of multi-layered process dependencies, Orchestrator detects and shows only the first level dependency for a given process.

For example, process A needs process B to start, and process B needs process C to start. The dependency hierarchy is A > B > C. In this case, when checking package requirements for process A, Orchestrator detects and displays the first level of dependency for it, that is process B. If process B is missing, you can add it from the Package Requirements tab, but if process C is missing, you need to identify it as missing yourself and add it manually.

Adding Action Catalogs

Orchestrator detects the action catalogs required to execute the process, but you cannot add the missing ones from the Package Requirements tab, as action catalogs are objects configurable via Action Center.

Prerequisites: Make sure you have Create permissions on the specific object and access to the folder you want to add the object to.

Proceed with the following steps:

1. Head over to the corresponding Action Center instance.
2. Access the Admin Settings page.
3. Select the process folder .
4. Click Add new catalog. Make sure to use the name detected as missing in the Package Requirements tab.
5. Click Create.

Adding time and queue triggers

Adding a time or a queue trigger prepopulates the fields on the Create Trigger page with the values set by the RPA developer in the associated trigger activity, during design-time. You can edit these values while the trigger has the Pending creation status or later from the Edit trigger page. The Pending creation status means the trigger is stored in a temporary memory until the process it needs is created.

1. Go to Automations > Processes and click Add process.
2. Select the package that contains the time trigger activity.
3. Input the required runtime arguments, then click Next.
4. The package requirements page displays the time trigger with the Missing status. Click the Add trigger button to configure the time trigger.
5. Configure the trigger properties as instructed on the Creating time triggers/Creating queue triggers page. The time/queue trigger status changes to Pending creation.
6. Click Next to continue configuring the process, and then click Create.
   Once the process is created, the time/queue trigger appears in the Time/Queue Triggers grid in Orchestrator.
   Adding queues from the queue trigger creation page

   You have the option to add a queue during the creation of a missing queue trigger. Be aware that doing so restricts you from adding SLAs to the queue until the trigger is created.

   
   

   

   
   

Configuring connected event triggers

1. In the folder context, navigate to Automations and select Processes, then Add process.
2. Select the package that contains the event trigger activity.
3. Select the entry point and enter the required runtime arguments, then select Next.
4. The Package Requirements page displays the event connection identified in the package. Select a connection or add a new one. For details, refer to Configuring connections.
5. The event trigger shows up under the corresponding connection, and has the Pending creation status. To edit the event trigger, select the pencil icon. The Edit Event Trigger page opens.
   Note: This step is optional. If you skip it, the default selections apply.
6. Enter a unique name for your trigger in the Name field. If the trigger name already exists, you receive an error message and must change the name.
7. From the Job Priority dropdown menu, select the priority of the job. The default value is Inherited, meaning that the job priority is the same as the one defined for the selected process.
8. From the Runtime type dropdown menu, select the runtime for executing the jobs that the trigger launches. If you want to use an unattended runtime, we recommend not setting the connection as Configurable by users.
9. In the Execution Target section, to select a job termination strategy, enable the Schedule ending of job execution toggle.
   Note:

   The amount of time you specify elapses according to the specifications, even if the job is queued. For example, if you schedule a job to run at 1 p.m. and set it to stop after 20 minutes, the job stops at 1:20 p.m. even if it had been in a queue until 1:15 p.m., and then started.

   Additionally, if you opt to stop a pending or running job after two hours and kill the same job after three hours, the job is killed after five hours. This happens because, first, Orchestrator receives the signal that the job was stopped after two hours. Upon receiving the signal, Orchestrator times the kill action to occur in three hours, thus resulting in a total of five hours.

   You have the following options:

   • Select Stop from the dropdown menu: This option initiates an attempt to gracefully end the job execution when the job has been in a pending or running state for the amount of time you set. You can set a minimum interval of one minute, and a maximum interval of 10 days, 23 hours and 59 minutes.
   • Select Kill from the dropdown menu: This option initiates an attempt to forcefully end the job execution when the job has been in a pending or running state for the amount of time you set. You can set a minimum interval of one minute, and a maximum interval of 10 days, 23 hours and 59 minutes.
   • Select Stop from the dropdown menu and enable the If the job does not stop, kill it option. This option initiates an attempt to gracefully end the job execution when the job has been in a pending or running state for the amount of time you set for the stop action. If the attempt results in the job remaining in a stopping state, Orchestrator then attempts to kill the job after the amount of time you set for the kill action. You can set a minimum interval of one minute, and a maximum interval of 10 days, 23 hours and 59 minutes.
10. To receive an alert if a job has remained in a pending or resumed state for a certain amount of time, enable the Generate an alert if the job is stuck in pending or resumed status toggle and set the acceptable duration for the job to remain in a pending or resumed state. The minimum configurable duration is one minute, and the maximum duration is eleven days. If the job exceeds the configured duration, an error-severity alert pop-up appears, with the following text: "N jobs for #process {process_number} have been pending or resumed for more than X hours and Y minutes.", where:
    • N is the number of jobs that triggered the alert.
    • {process_number} is the process identifier.
    • X is the configured number of hours that the job exceeded while in a pending or resumed state. Days are converted to hours.
    • Y is the configured number of minutes that the job exceeded while in a pending or resumed state.
11. To receive an alert if a job has not completed within a set interval, enable the Generate an alert if the job started and has not completed toggle and set the acceptable duration for the job to complete. The minimum configurable duration is one minute, and the maximum duration is eleven days. If the job exceeds the configured duration, an error-severity alert pop-up appears, with the following text: "Job for #process {process_number} has been running for more than X hours and Y minutes.", where:
    • {process_number} is the process identifier.
    • X is the configured number of hours that the job exceeded without completing. Days are converted to hours.
    • Y is the configured number of minutes that the job exceeded without completing.
12. To keep the same account-machine context configured for starting the job, select Keep Account/Machine allocation on job resumption. Selecting this option optimizes your license and resource usage.
13. In the Runtime Arguments section, select an entry point from the dropdown menu and provide appropriate values for process arguments, then select Update to save the event trigger configuration.
14. To continue configuring the process, select Next. When you are done, select Create.

Note:

Execution-based trigger disabling applies only to event triggers published from Studio Web to personal workspaces.

By default, triggers are disabled after 5 consecutive failed executions. You can update the configuration by editing the following tenant-level execution settings:

• Triggers - Connected triggers - Disable when job execution fail count

• Triggers - Connected triggers - Grace period when job execution keeps failing count (days)

Once the process is created, the event trigger appears in the Event Triggers grid, with the Connected value in the Type column.

Configuring Connections

Note: This functionality is available only in personal workspaces.

Orchestrator allows specifying the account used in a connection when creating a new process or editing an existing one.

As an admin, you can configure the connection for your users in their own personal workspace, provided you have the following set of permissions:

• View permissions on Connections

• View, Edit permissions on Personal Workspaces

• View, Edit permissions on Resource Overwrites

1. Go to Automations > Processes in your personal workspace. The Processes page is displayed.
2. Click More Actions > Edit next to a process to edit it. The Edit Process window is displayed.
3. On the Process Configuration tab, configure the general details of the process as needed.
4. Go to the Packages Requirements tab to see the objects used by the underlying automation project. Here you should see all the connections that have been added in the automation project at design-time. A connection groups all the activities that were configured to use it. One of the following options is displayed:
   Figure 1.

   Connection option	Behavior	Notes
   An existing connection	The activity executes for the selected shared connection.	Available connections are organized under their container folders.
   Configurable by users	Allows users to select their own connection at runtime in UiPath Assistant.	Do not select this option for unattended runtimes.
   No permissions or missing connection	Check for View permissions in the folder that contains the connection you need.	You can add missing connections in the current folder by clicking the cog icon > Add connection. Clicking the cog icon > Manage connections redirects you to the Integration Service interface, where you can create new connectors and connections.

5. Click the cog button to manage your connections or add new ones via Integration Service.
   
   

   

   
   

   The Configurable by users option

   The Configurable by users option is displayed by default in the following situations:

   • The package is published to a personal workspace

   • The connection is unshared (it resides in a folder you cannot access)

   • The connection does not exists

   • Insufficient permissions

   If you manually set the Configurable by users option, you allow your users to select their own connection at runtime, in UiPath Assistant.

   Integration Service activity filters

   An activity from Integration Service can contain filters. The filter values depend on the connection used, and can be overwritten at runtime in UiPath Assistant. Only activities with filters that can be overwritten are displayed as package requirements.If the connection is set to Configurable by users, no filters are displayed.

   Note:

   Changing an existing connection to Configurable by users resets the activity filters. This way, users can configure their own filters.

   Using other connection than the existing one resets the activity filters. This way, you can set new filters for the new connection.

   To run unattended automations, a connection for a service account must be set. You must not set the Configurable by users option.

Customizing User Configurations

When an event trigger has the Configurable by users option selected, your users can set their own connections at runtime, in UiPath Assistant.

The Custom user configurations page lists the event trigger configurations set by your users.

As a folder administrator, you can override users existing configurations or add new ones at process or at trigger level.

Exploring the personal workspace of a user

• Setting a configuration for your users implies exploring the personal workspace of the selected user.

• To add connections on behalf of your users, you need to see their personal connections, which reside in their Personal Workspace folder.

• Users receive an alert whenever you begin or end exploring their personal workspace.

User configuration statuses

These statuses help you identify which users has a faulty configuration:

Configured - the user has a working configuration.

Partially configured - the user has a faulty configuration, which may imply missing connections.

Accessing the Custom user configurations page

You can access the Custom user configurations page from both the Processes and the Event Triggers pages.

1. In the selected folder, go to:

   Option	Description
   Automations > Triggers > Event triggers	A list of all available event triggers is displayed.
   Automations > Processes	A list of all available processes is displayed.

2. For the desired process/event trigger, click the More Actions button, and then select Custom user configurations. This redirects you to the Custom user configurations page.

Adding a new user configuration

1. For the desired process or event trigger, access the Customer user configurations page.
2. In the Package requirements configurations per user account section, click Add user configuration. The Configure process requirements for user account wizard opens.
3. From the User account dropdown, select the user for which you want to configure the process or the event trigger, then click Add user.
   Note:

   • The selected user must be in the same folder as the process/event trigger. Otherwise, you are prompted to assign the user in the folder.
   • If, in the meantime, you remove users from the folder, their user configuration continues to show up in the list.
   • A pop-up message informs you about the need to explore the personal workspace of the selected user.
4. Provide the required details, such as connections or activity filters.
5. Save the configuration.

Overriding an existing user configuration

1. For the desired process or event trigger, access the Customer user configurations page.
2. For the desired user account, click Edit configuration.
3. Modify the required details, such as connections or data filters.
4. Update the configuration by clicking Save.

   In Assistant, users with proper Resource Overwrites permissions can always update the settings you have configured.

Removing the event trigger configuration of a user

To remove the event trigger configurations of your users:

1. For the desired process or event trigger, access the Customer user configurations page.
2. For the desired user account, click Clear configuration. This operation clears the configurations of the selected user.
   If a user has their configurations removed, the process may not run as expected.
   Note:

   To make changes on the Customer user configurations page, the following permissions are required:

   • At the event trigger level, this operation requires Edit permissions on Resource overwrites, and View permissions on Triggers.
   • At the process level, this operation requires Edit permissions on Resource overwrites, View and Edit permissions on Processes.