Deploying Automations | MuleSoft Documentation
# Deploying Automations
The third phase of process automation is the **Test** phase. In this phase, you can test the implemented process model in different configurations. You can transition back to **Build** phase to change the implementation.
When the tests are successful, transition to **Production** phase.
The **Production** phase is the final phase in the life cycle of a process.
You have three ways to run a process:
  * Create and deploy a **Scheduled Run Configuration** to run the process automatically at defined times.
  * Create and publish an **Invocable Run Configuration** to use it within other Salesforce products.
  * Create an **On-Demand Run Configuration** to start the process run manually.


You can’t run processes openly in existing console sessions or run them hidden in Secure Sessions. In console sessions, only one process can run at a time. In Secure Sessions, different processes or several instances of the same process can run in parallel.
## Before You Begin
  * Ask an organization administrator in Access Management to assign you the required permissions:
Action | RPA Permission | Deprecated RPA Permission  
---|---|---  
Open the **Process Automation** module. | RPA Automations Designer, RPA Automations Contributor, RPA Automations Manager, RPA Administrator | Process Automation Open  
  * At least one RPA Bot must be installed to deploy or publish a process.
    * Be aware that bots can reside in different time zones.
  * If you want to use the values of global variables or credentials as initial values for activity parameters, an RPA administrator must create them in the **Global Variables** or **Credential Pool** view first.
  * A project in test or production phase must exist in the **Project Management** view of the **Process Automation** module.
  * Obtain the needed permissions as a member of the process team in the project data sheet in the **Project Management** view of the **Process Automation** module.
  * To run a process in an existing console or RDP session, you must deploy it to a bot that is configured for console sessions, and the specified user must be logged in to this session when you deploy the run configuration. If the user is logged in more than once, the bot starts the process in the first session in which the user is logged in. The bot searches for the user in this order:
    1. Physical console session
    2. RDP session 1
    3. RDP session …​
    4. RDP session .
Bots running an earlier version than 1.2.0 overtake an open console session without checking if the logged-in user matches the specified user.   
---  
Don’t close or minimize the console session while the bot executes the process.
  * To run a process in a hidden session, you must deploy it to a bot configured for Secure Sessions. Before deploying a run configuration on a bot that has only one licensed secure session, don’t disconnect the session, instead sign out the specified user. Don’t sign in to a computer where a bot with one licensed Secure Session is running a process.
  * RPA Manager requires authentication to integrate RPA processes into other Salesforce products:
    * Use user API keys to use Salesforce Flows with RPA.
    * Use Connected Apps to configure an RPA connector in a MuleSoft Composer flow.


## Test a Process Automation
Transition the project to the test phase and create test configurations to execute test runs.
Test configurations contain start values for the activity parameters defined in RPA Builder, users who process the user tasks, the configuration of the test environment, and the executing bots.
Transition the project back to the build phase to change the implementation.
### Transition Process to Test Phase
Transition the fully implemented process to test phase for testing:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **Publish (Test)**.
  4. In the window **Release to Test** , add the needed applications.
  5. Check **I confirm that the process should be released into the test phase and all responsible persons have agreed.**
  6. Click **Release to Test** to confirm the transition.


### Create a Test Configuration
To create a test configuration:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **Create new test plan**.
  4. Complete the **Create test plan** wizard:
     * **Activity Parameter**
The activity parameters for each process are created in RPA Builder and are given initial values there. You can overwrite these values with new initial values by double-clicking on the relevant field in the **Value** column.
Set a value by entering text or by clicking on a checkbox, and complete your entry by pressing ENTER.
Alternatively, you can set the value of an activity parameter by linking it with a global variable. To link the parameter to a variable, click **Link a global activity parameter** () and select a variable. RPA Manager displays variables of the same type, assigned to the test phase, and only the credentials to which you’re affiliated. If a credential affiliated to another user is already linked, RPA Manager displays a row of stars to hide the data.
The variables are typed. You can only enter or link values of the same type. The values entered here are start values, which can be overwritten by other values during the process run.
     * **User Task**
User tasks are elements of a process model, which can’t be processed fully automatically by a bot, but which require the support of a human. Specify which users are to process the user tasks by clicking on the **User Assignment or User Group Assignment** icon. The number of assigned users and user groups is displayed in the table. You can specify both users and user groups at the same time. The user task is then displayed to each specified user until a user reserves it for processing.
Select the checkbox **Send email notification to all related users** when the task is ready for processing if you want all specified users to receive an email as soon as they’re supposed to process a user task. This email contains the name of the user task, the process, and the project manager, as well as a prompt to review the pending tasks in the **My RPA** module.
     * **Execution**
Decide whether to carry out the test run in an existing console or RDP session or in a Secure Session, and specify an appropriate user.
You can link the user with a global credential variable by clicking on the **Link a credential from credential pool** icon.
Use the syntax `domain\username` instead of `username@domain.com` for domain users and `username` for local users, regardless of whether you enter the username manually or link a global credential.
Ensure that the bot that you want to execute the process is configured for the execution type, because you can’t save the test configuration otherwise.
The bot can overtake the console or RDP session only if the specified user is logged in at runtime. If no user or another user is logged in at runtime, the process run results show the failure **No active session with the user ' <user name>' could be found on the system**.
Bots running an earlier version than 1.2.0 overtake an open console session without checking if the logged-in user matches the specified user.   
---  
If you want to watch the execution of the process in the **Process Streaming** view of the **Process Monitoring** module or if the process uses elements of the Windows operating system like the start menu or the task bar, check **Enable Taskbar (Start menu, taskbar buttons)**.
     * **Bots**
Select all RPA Bots that are to carry out the test configuration.
Select the checkbox **Show bots not enabled in this phase** to also show bots that aren’t intended for use in this phase.
When you select a bot, ensure that it’s configured for the required session type, that it’s allowed to be deployed in the relevant phase, and that it can operate the required applications.
If one of the selected bots isn’t configured appropriately, RPA Manager displays a notification, and you can’t proceed with the test configuration. Hover the mouse pointer over the info label to display more detailed information about the cause of the warning or error in the form of a tooltip.
  5. Click **Finish**.


### Run Tests
Run all tests in parallel. RPA Manager shows a warning in case of deployment problems.
View the results in the **Test Results** panel:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **Start tests**.
  4. In the window **Select Configuration to deploy** , check all test configurations you want to run.
  5. Click **Execute**.
### Run Tests
Run all tests in parallel. RPA Manager shows a warning in case of deployment problems.
View the results in the **Test Results** panel:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **Start tests**.
  4. In the window **Select Configuration to deploy** , check all test configurations you want to run.
  5. Click **Execute**.


### View Test Results
View the test results to decide if the project can transition to production phase. In case of errors, download an analysis package and open it in RPA Builder.
To view the test results and to download an analysis package:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. In the panel **Test Results** , select a time interval and click **Update**.
  4. View the run results in the table.
  5. If you want details on a result, click a number.
  6. In case of errors, click the **Download** icon.


## Deploy a Process Automation
Transition the project to the production phase to deploy a run configuration to a bot. The process runs fully automated from now on.
Sometimes it’s necessary to start a process manually when something happens that only a human can evaluate. For example, the goods inwards inspection process can only start after the banana delivery ship reaches the pier wall. For this purpose, use the **Run Now** option.
You have three ways to run a process:
  * Create and deploy a **Scheduled Run Configuration** to run the process automatically at defined times.
  * Create and publish an **Invocable Run Configuration** to use it within other Salesforce products.
  * Create an **On-Demand Run Configuration** to start the process run manually.


You can run processes openly in existing console sessions or hidden in Secure Sessions. In console sessions, only one process can run at a time. In Secure Sessions, different processes or several instances of the same process can run in parallel.
Pause or revoke configurations to stop the execution temporarily. Transition the project back to the build phase to change the implementation.
You can’t delete projects of processes that a bot has already run productively.
### Transition Process to Production Phase
Transition the tested process to production phase for running it fully automatically or for publishing it to Anypoint Exchange:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **Publish (Production)**.
  4. In the window **Release to Production** , add the needed applications.
  5. Check **I confirm that the process should be released into the production phase and all responsible persons have agreed.**
  6. Click **Release to Production** to confirm the transition.


### Create a Run Configuration
A run configuration consists of a name, a description, initial values for the Activity Parameters, one or more bots, and conditions for deployment of the automation with this configuration.
There are three types of run configurations:
  * **Scheduled run configurations** define intervals for the runs.
  * **Invocable run configurations** are called from other products. Automations can have one invocable run configuration.
  * **On-demand run configurations** are started manually.
You can publish an invocable run configuration after you save it.
You can create a new configuration or copy an existing one.
To create a new run configuration:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **New** > **< Type> Run Configuration**.
  4. Complete the **Create production configuration** form. The shown parameters depend on the configuration type:
     * **Settings**
       * **Priority**
Enter a number between 1 and 200 to specify the priority of the process run. Deployed processes are inserted in a session queue according to their priority. Process configurations with lower numbers are considered higher priority and are executed before configurations of lower priority. Invocable and on-demand run configurations always have highest priority.
     * **Activity Parameter**
The activity parameters for each process are created in RPA Builder and are given initial values there. You can overwrite these values with new initial values by double-clicking on the relevant field in the **Value** column.
Set a value by entering text or by clicking on a checkbox, and complete your entry by pressing ENTER.
Alternatively, you can set the value of an activity parameter by linking it with a global variable. To link the parameter to a variable, click **Link a global activity parameter** () and select a variable. RPA Manager displays variables of the same type, assigned to the production phase, and only the credentials to which you’re affiliated. If a credential affiliated to another user is already linked, RPA Manager displays a row of stars to hide the data.
The variables are typed. You can only enter or link values of the same type. The values entered here are start values, which can be overwritten by other values during the process run.
     * **User Task** :
User tasks are elements of a process model that a bot can’t process fully automatically and require human intervention. Specify which users are to process the user tasks by clicking on the **User Assignment** or **User Group Assignment** icon. The table displays the number of assigned users and user groups. You can specify both users and user groups at the same time. The user task is then displayed to each specified user until a user reserves it for processing.
Select the checkbox **Send email notification to all related users** when the task is ready for processing if you want all specified users to receive an email as soon as they’re supposed to process a user task. This email contains the name of the user task, the process, and the project manager, as well as a prompt to review the pending tasks in the **My RPA** module.
     * **Execution** :
Decide whether to carry out the productive run in an existing console or RDP session or in a Secure Session, and specify an appropriate user.
You can link the user with a global credential variable by clicking on the **Link a credential from credential pool** icon.
Use the syntax `domain\username` instead of `username@domain.com` for domain users and `username` for local users, regardless of whether you enter the username manually or link a global credential.
Ensure that the bot that you want to execute the process is configured for the execution type, because you can’t save the run configuration otherwise.
The bot can overtake the console or RDP session only if the specified user is logged in at runtime. If no user or another user is logged in at runtime, the process run results show the failure **No active session with the user ' <user name>' could be found on the system**.
Bots running an earlier version than 1.2.0 overtake an open console session without checking if the logged-in user matches the specified user.   
---  
If you want to watch the execution of the process in the **Process Streaming** view of the **Process Monitoring** module or if the process uses elements of the Windows operating system like the start menu or the task bar, check **Enable Taskbar (Start menu, taskbar buttons)**.
     * **Schedule** :
**Note that bots might run in different time zones.**
You create a schedule without specifying a time zone. The bot you assign the production configuration to executes the process at the specified times in its local time. The time intervals might change, depending on daylight saving time.
For example, if you work in Buenos Aires (ART (UTC -3)), specify a schedule that starts at 5:30 AM and ends at 9:30 PM and assign the configuration to three bots installed on computers in Berlin, San Francisco, and Tokyo, the bots don’t execute the processes simultaneously:
**Execution Time in the Bot’s Local Time Zone** | **Execution Time in the Buenos Aires User’s Local Time Zone**  
---|---  
Berlin bot | 5:30 AM - 9:30 PM (Berlin time, (CET (UTC +1)) = | 1:30 AM - 5:30 PM (Buenos Aires time (ART (UTC -3)))  
San Francisco bot | 5:30 AM - 9:30 PM (San Francisco time, (PST (UTC -8)) = | 10:30 AM - 2:30 AM (Buenos Aires time (ART (UTC -3)))  
Tokyo bot | 5:30 AM - 9:30 PM (Tokyo time, JST (UTC +9)) = | 5:30 PM - 9:30 AM (Buenos Aires time (ART (UTC -3)))  
The bot checks every minute whether it’s within a scheduled time frame and within its service time and whether the required process applications are outside all downtimes. The process isn’t executed if the executing bot is outside its service time or if one or more of the process applications used by the bot are within a downtime.
Invocable and on-demand run configurations don’t have schedules.
For a scheduled run configuration, choose the schedule type:
Interval and Cron expression scheduling are supported by bots running version 1.7.0 or later.   
---  
       * **Interval** Enter the interval to repeat the process. The process starts once at the beginning of each interval.
The intervals are equidistant in the defined time frame. For example, `Repeat my process every 10 minutes`.
If you need a more complex interval, use **Cron expression**.
       * **Cron expression**
Enter a Cron expression to repeat the process. The process starts once at the beginning of each interval.
The intervals aren’t equidistant. For example, `Run my process on minutes 3, 11, and 48 of every hour between 08:00 AM and 10:42 PM, only on Monday and Friday, from February to April, and in November`.
If you need a simpler interval, use **Interval**.
You can use the Cron expression helper to compile the expresssion and check the natural language schedule summary.
What is a Cron expression?
Cron is a widely used standard for describing time and date information. You use a cron expression to define complex intervals, for example, `Run my process on minutes 3, 11, and 48 of every hour between 08:00 AM and 10:42 PM, only on Monday and Friday, from February to April, and in November.
The scheduler keeps track of every minute and starts the process run when the Cron expression matches the bot’s time-date setting. You can trigger the event just once or at regular intervals.
A date-time expression in the Cron format used by RPA Manager consists of five required settings in the following order:
         1. Minutes (`0`-`59`)
         2. Hours (`0`-`23`)
         3. Day of month (`1`-`31`)
         4. Month (`1`-`12`)
         5. Day of the week (`0`-`7`), where Sunday is either `0` or `7`
The Scheduler component also supports the following special characters:
         * `*`: All values within the range of valid values.
         * `-`: Range of values within the range of valid values, for example, `1-3`.
         * `,`: Additional values within the range of valid values, for example, `1,7`.
         * `/`: Incremental values within the range of valid values starting with the first specified value, for example, `1/7`.
You can set either the day of the week or day of the month, but not both. Replace either the day of the week or day of the month with an asterisk.
The Scheduler supports most standard Cron expressions. Here are a few good and bad examples:
Expression | Behavior | Explanation  
---|---|---  
`5 4 3 2 1` | At 04:05 AM on every Monday in every February and (?) on the 3rd of every February | This Cron expression is invalid. You can set either the day of the week or the day of the month, but not both. Replace either the day of the week or the day of the month with an asterisk. If you want to run a process exactly once at a specific time, you must specify the day of the month but not the day of the week. See the next two examples.
The Scheduler component also supports the following special characters:
         * `*`: All values within the range of valid values.
         * `-`: Range of values within the range of valid values, for example, `1-3`.
         * `,`: Additional values within the range of valid values, for example, `1,7`.
         * `/`: Incremental values within the range of valid values starting with the first specified value, for example, `1/7`.
You can set either the day of the week or day of the month, but not both. Replace either the day of the week or day of the month with an asterisk.
The Scheduler supports most standard Cron expressions. Here are a few good and bad examples:
Expression | Behavior | Explanation  
---|---|---  
`5 4 3 2 1` | At 04:05 AM on every Monday in every February and (?) on the 3rd of every February | This Cron expression is invalid. You can set either the day of the week or the day of the month, but not both. Replace either the day of the week or the day of the month with an asterisk. If you want to run a process exactly once at a specific time, you must specify the day of the month but not the day of the week. See the next two examples.  
`5 4 3 2 *` | At 04:05 AM on the 3rd of every February | If you want to run a process exactly once at a specific time, you must specify the day of the month but not the day of the week. You can’t specify the year.  
`5 4 * 2 3` | At 04:05 AM on every Wednesday of every February | If you want to run a process exactly once at a specific time, you must specify the day of the month but not the day of the week. You can’t specify the year.  
`*/7 * * * *` | At minute 00, 07, 14, 21, 28, 35, 42, 49, 56 of every hour (of every day of every month on every weekday). | Starts at minute 0 because it’s the first of all values in the valid range (*).  
`45/05 * * * *` | At minutes 45, 50, and 55 of every hour  
`* * * * *` | Every minute forever  
`* 9-16 * * 1-5` | Every minute, between 09:00 AM and 04:59 PM, Monday through Friday  
`00,10,42 9-16 1-10,20-30 2-7,12 *`` | At 0, 10, and 42 minutes past the hour, between 09:00 AM and 04:59 PM, on day 1 through 10 and 20 through 30 of the month, and on Friday, only in February through July and December | You can combine lists and ranges.  
Non-existent times, such as 'missing hours' during daylight savings conversion, never match the bot’s time-date setting, causing processes scheduled during the 'missing times' not to run. Times that occur more than once (again, during daylight savings conversion) cause matching processes to run twice.
       * **Calendar Scheduling**
Use this option to edit run configurations that already use calendar scheduling.
Add one or more fixed schedules within which RPA continuously executes the productive run. For each schedule, define time intervals within which RPA executes the process. RPA Manager combines all schedules to compute the execution times.
How does calendar scheduling work?
You can create multiple overlapping schedules. All schedules together make up a time frame within which the bots may start the process runs continuously. A new process run doesn’t start until all conditions are fulfilled.
For this reason, the executing bot checks every minute whether it’s within a service time and whether the required process applications are outside all downtimes. The process isn’t executed if the executing bot is outside its service time or if one or more of the process applications used by the bot are within a downtime.
Unless the computer on which the bot is installed crashes or an required application is down, running processes are always completed.
When creating new schedules, pay attention to whether the new schedules overlap with schedules of other configurations and ensure that the executing bots have enough free sessions. Otherwise, the bot might skip process runs.
Click on the button **Add Schedule** to assign a (further) schedule to this configuration and complete the **Create a new schedule** form:
         * **From** :
Start of the time interval. As of this time, the scheduled action is executed. The start time must not be in the past and it must not be later than the end time. Even if you specify a Repeat on a specific day of the week or month that does not correspond to the start time, the schedule is started at this time anyway. The day specified under Repeat is then taken into account from the first repetition onward.
         * End of the time interval. As of this time, the scheduled action is no longer executed. The end time must not be earlier than the start time. If you use the Repeat option, the duration of the time interval is defined by the difference between the From and To times.
         * **All day** :
Select the checkbox **All day** to execute the action throughout the day. It then begins on the first day at 12:00 midnight and stops being executed at 12:00 midnight of the next day (in the case of one-day intervals) or at 12:00 midnight on the day after the last day (in the case of multi-day intervals).
         * **Repeat** :
Select the checkbox **Repeat** if the selected time interval is to be used repeatedly.
Then, under **Repeats** , you can choose whether the **From-To** time interval is to be repeated every minute, hourly, daily, weekly, monthly, or yearly.
The duration of the contained time interval and the start time are taken into account. The duration of the time interval is defined as the difference between the **From** and **To** times. The **From** time is the start time of the first execution. The start time of repetitions depends on the other set values.
To execute the repeats only with reference to the time of day, you should ensure that the start and end dates are identical. If the interval specified covers multiple days, a new multi-day interval begins with every repetition. This can lead to a situation in which the scheduled time interval lasts longer than expected because the full number of days contained in the **From-To** interval is executed once again during the last repetition.
With schedules that are not all day, the actions in each repetition are executed for the duration of the interval specified in the **From** and **To** fields.
           * **Repeat minutely** :
If you select **Repeat minutely** , the planned action is executed every minute during the interval specified in the **To** and **From** fields.
You can select whether you want to repeat the action every minute or only every _n_ -th minute. _n_ here stands for any integer number between 1 and 59.
           * **Repeat hourly** :
If you select **Repeat hourly** , the planned action is executed hourly during the interval specified via **To** and **From**. You can select whether you want to repeat the action every hour or only every _n_ -th hour, where _n_ here stands for any integer number between 1 and 23.
           * **Repeat daily** :
If you select **Repeat daily** , the planned action is executed daily during the interval specified via **To** and **From**.
You can select whether you want to repeat the action every day or only every _n_ -th day. _n_ here stands for any integer number between 1 and 31.
           * **Repeat weekly** :
If you select **Repeat weekly** , the planned action is executed weekly during the interval specified via **To** and **From**.
You can select whether you want to repeat the action every week or only every _n_ -th week. _n_ here stands for any integer number between 1 and 52.
You can also select the weekday on which the scheduled action is to be executed.
           * **Repeat monthly** :
If you select Repeat monthly, the planned action is executed monthly during the interval specified via **To** and **From**.
You can select whether you want to repeat the action every month or only every _n_ -th month. _n_ here stands for any integer number between 1 and 12.
You can also choose whether the repeat refers to the day of the month or the day of the week.
If the selected day is the last day of a month, you can also choose whether the execution day is always the last day of a month, as the number of days in each month is different.
If the selected day is the fourth such weekday of a month, you can also choose whether the execution day is always the fourth or last such weekday of a month, as the number of weeks in each month is different.
           * **Repeat yearly** :
If you select **Repeat yearly** , the planned action is executed annually during the interval specified via **To** and **From**.
You can select whether you want to repeat the action every year or only every _n_ -th year. _n_ here stands for any integer number between 1 and 20.
You can also select the weekday on which the scheduled action is to be executed.
           * **Repeat monthly** :
If you select Repeat monthly, the planned action is executed monthly during the interval specified via **To** and **From**.
You can select whether you want to repeat the action every month or only every _n_ -th month. _n_ here stands for any integer number between 1 and 12.
You can also choose whether the repeat refers to the day of the month or the day of the week.
If the selected day is the last day of a month, you can also choose whether the execution day is always the last day of a month, as the number of days in each month is different.
If the selected day is the fourth such weekday of a month, you can also choose whether the execution day is always the fourth or last such weekday of a month, as the number of weeks in each month is different.
           * **Repeat yearly** :
If you select **Repeat yearly** , the planned action is executed annually during the interval specified via **To** and **From**.
You can select whether you want to repeat the action every year or only every _n_ -th year. _n_ here stands for any integer number between 1 and 20.
         * **Ends** :
If you select **Never** under Ends, the time period is repeated over and over.
If you select **After n occurrences** under **Ends** , the time period is repeated _n_ times. _n_ here stands for any integer number between 1 and 100.
If you select **Ends on <date>**, the time interval is no longer repeated after this date.
     * **Bots** :
Select all RPA Bots that are to carry out the production configuration.
Select the checkbox **Show bots not enabled in this phase** to also show bots that aren’t intended for use in this phase.
When you select a bot, ensure that it’s configured for the required session type, that it’s allowed to be deployed in the relevant phase, and that it can operate the required applications.
If one of the selected bots isn’t configured appropriately, RPA Manager displays a notification, and you can’t proceed with the configuration. Hover the mouse pointer over the info label to display more detailed information about the cause of the warning or error in the form of a tooltip.
Set the number of Secure Sessions for each bot. On-demand run configurations have only one session.
  5. Click **Save**.
### Copy a Run Configuration
Copy a run configuration if you need to change only a few parameters.
You can also copy a scheduled or an invocable run configuration as an on-demand run configuration.
To copy a run configuration:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click the **Copy** icon () in the table row of the run configuration to copy.
  4. Select the type of the copy.
  5. Enter a new name for the copy of the run configuration. The copy contains all assets of the original. For on-demand run configurations, the number of sessions of all bots is set to 1.
  6. Click **OK**.


You can edit the copy after saving.
### Deploy Configurations
Deploy configuration to run them fully automatically in a productive environment:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **Select action**.
  4. From the dropdown, select **Deploy process**.
  5. In the window **Select Configuration to deploy** , check all configurations to run.
  6. Click **Execute**.


### Run a Configuration Once
The configuration to run once must either be invocable or marked as **Start Manually**.
To start the single process run:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **Select action**.
  4. From the dropdown, select **Run once**.
  5. In the window **Select Configuration to Run once** , check all configurations to run.
  6. Click **Execute**.


The run starts directly. If an invocable configuration is triggered at the same time using the same session, the run waits for the invocable run to complete before starting.
### View Run Results
View the run results to check if everything runs as predicted. In case of errors, download an analysis package and open it in RPA Builder. You can always transition the project back to build phase.
To view the run results and to download an analysis package:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. In the panel **Run Results** , select a time interval and click **Update**.
  4. View the run results in the table.
  5. If you want details on a result, click a number.
  6. In case of errors, click the **Download** icon.


## Publish a Process Automation
Transition the project to the production phase and publish an invocable run configuration to use the process out of MuleSoft RPA, for example with one of the following products:
  * Anypoint Exchange
  * MuleSoft Composer
  * Salesforce Flow via Anypoint Exchange


You can’t delete projects once they’re used in production.
Deleted invocable run configurations aren’t deleted in Anypoint Exchange. Edited and updated invocable run configurations are published as new versions in Anypoint Exchange.
Invocable configurations can run only if the following requirements are met:
  * The project is in the production phase.
  * At least one of the assigned bots is in the `OK` state.


### Transition Process to Production Phase
Transition the tested process to production phase for running it fully automatically or for publishing it:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **Publish (Production)**.
  4. In the window **Release to Production** , add the needed applications.
  5. Check **I confirm that the process should be released into the production phase and all responsible persons have agreed.**
  6. Click **Release to Production** to confirm the transition.


### Create an Invocable Run Configuration
You can publish an invocable run configuration after you save it.
To create an invocable run configuration:
  1. Open the **Process Management** view of the **Process Automation** module and click on the name of the category of your project.
  2. Click on the name of a project to open it.
  3. Click **New** > **Invocable Run Configuration**.
  4. Complete the **Create production configuration** form:
     * **Activity Parameter** :
The activity parameters for each process are created in RPA Builder and given initial values there. You can overwrite these values with new initial values by double-clicking on the relevant field in the **Value** column.
Set the value by entering text or by clicking on a checkbox, and complete your entries by pressing ENTER.
Alternatively, you can set the values of the activity parameters by linking them with a global variable. To do this, click on the **Link a global activity parameter** icon. Only those variables assigned to the phase are displayed for linking. The variables are typed. You can only enter or link values of the same type. The values entered here are start values, which can be overwritten by other values during the process run.
     * **User Task** :
User tasks are elements of a process model, which can’t be processed fully automatically by a bot, but which require the support of a human. Specify which users are to process the user tasks by clicking on the **User Assignment or User Group Assignment** icon. The number of assigned users and user groups is displayed in the table. You can specify both users and user groups at the same time. The user task is then displayed to each specified user until a user reserves it for processing.
Select the checkbox **Send email notification to all related users** when the task is ready for processing if you want all specified users to receive an email as soon as they’re supposed to process a user task. This email contains the name of the user task, the process, and the project manager, as well as a prompt to review the pending tasks in the **My RPA** module.
     * **Execution** :
Decide whether to carry out the invocable run in an existing console or RDP session or in a Secure Session, and specify an appropriate user.
You can link the user with a global credential variable by clicking on the **Link a credential from credential pool** icon.
Use the syntax `domain\username` instead of `username@domain.com` for domain users and `username` for local users, regardless of whether you enter the username manually or link a global credential.
Ensure that the bot that you want to execute the process is configured for the execution type because you can’t save the run configuration otherwise.
The bot can overtake the console or RDP session only if the specified user is logged in at runtime. If no user or another user is logged in at runtime, the process run results show the failure **No active session with the user ' <user name>' could be found on the system**.
Bots running an earlier version than 1.2.0 overtake an open console session without checking if the logged-in user matches the specified user.   
---  
If you want to watch the execution of the process in the **Process Streaming** view of the **Process Monitoring** module or if the process uses elements of the Windows operating system like the start menu or the task bar, check **Enable Taskbar (Start menu, taskbar buttons)**.
     * **Bots** :
Select the RPA Bots to carry out the invocable configuration.
Select the checkbox **Show bots not enabled in this phase** to also show bots that aren’t intended for use in this phase.
When you select a bot, ensure that it’s configured for the required session type, that it’s allowed to be deployed in the relevant phase, and that it can operate the required applications.
If one of the selected bots isn’t configured appropriately, RPA Manager displays a notification, and you can’t proceed with the configuration. Hover the mouse pointer over the info label to display more detailed information about the cause of the warning or error in the form of a tooltip.
  5. Click **Save**.


### Publish an Invocable Run Configuration
You can publish an invocable run configuration to Anypoint Exchange.
To publish an invocable run configuration:
  1. Open the **Process Management** view of the **Process Automation** module and click on the category name of your project.
  2. Click on the name of a project to open it.
  3. Click **Publish** ().
  4. Click **Publish to Anypoint**.


If you edit your process or project, republish it to Anypoint to create a new version there.
## See Also
  * RPA Builder Overview
  *   *   *   * Connecting to RPA Processes from Salesforce Products
  * Secure API Integration with Connected Apps
  * MuleSoft RPA Connector for Composer
  * Salesforce: Use Flows with MuleSoft RPA