# Recommendations for Creating Commercial Scenarios

When developing commercial scenarios on the Sherpa RPA platform, it is important to adhere to the following requirements and recommendations:

1. **Ensuring Continuous Operation.**

The scenario must be designed to operate 24 hours a day without failures or interruptions, so all blocks must either contain alternative error handling scenarios via the "If Error" connector or the error handling mode must be set to Ignore, with one of the following blocks in the scenario ensuring the handling of error situations. Thus, the resilience of the scenario to the appearance of unforeseen controls on the screen, delays in application and internet performance must be ensured. In such cases, the currently processed item should be skipped, and the scenario should be correctly restarted to proceed to the next item being processed.

For example, the input data of the scenario contains 10,000 product names for which prices need to be collected. The developer runs the scenario overnight, and in the morning discovers that the scenario crashed 30 minutes after starting, and the robot did not complete the scenario. Therefore, the issues of scenario reliability and the development of various scenarios are very important.

2. **Ensuring Scenario Resilience.**

To ensure the resilience of the scenario, all blocks for interacting with the user interface and website pages (in visual mode) should specify non-zero (adequate) timeouts and wait periods. It is necessary to refrain from using unconditional waits and delays wherever not dictated by extreme necessity. Instead of unconditional delays, it is necessary to wait for the appearance of the controls needed to continue the scenario within a finite time. In the event of any scenario failure and subsequent restart, the scenario should continue working (approximately) from the point where it previously stopped.

3. **Ensuring Adequate Volume of Debug Messages in the Log.**

The scenario should write an adequate volume of debug messages to the log, which will allow understanding the progress of task processing and at what stage the robot is currently located.

4. **Ensuring Proper Operation of Opened Files.**

All files opened for reading or editing must be closed in a timely and correct manner, without delaying the file lock by the robot longer than necessary. When opening files, there should be a provision for the possibility that they are locked by another application. This is relevant when employees of the client company need to work with the file that the robot is handling. For example, the robot was scheduled to run overnight, and during the day, employees need to work with the same file. If the robot does not close it, employees will not have the opportunity to edit it.

5. **Recommendations for Scenarios Manually Triggered by Users.**

For scenarios that are manually triggered by users, it is recommended to display a message at the end of the scenario execution indicating whether it was completed successfully or not, and with what results.

6. **Recommendations for Developing Scenarios Intended for Scheduled Operation.**

* For scenarios intended for scheduled operation, it is unacceptable to display error messages in the form of dialog boxes. All errors should be logged, and the scenario should make every effort to continue working correctly.
* Scenarios intended for scheduled operation must restore the system environment to the state it was in at the time of launch, regardless of how they were stopped (planned or emergency) – so that the subsequent launch of the same scenario occurs correctly. It is unacceptable to accumulate resources, open and unclosed browser/application windows, etc.

7. **Recommendations for Developing Attended Robots.**

* The attended robot should regularly inform the user about the current stage of work and the document being processed (website, etc. - depending on the logic of the business scenario) with a message at the top of the screen (for this, the "Display in Status" flag should be set in the "Log" block).
* It is necessary to configure message output so that no more than one message is displayed per second and at least one message every 10 seconds.
* The most significant part of the message text for the user should come first and be displayed on the screen.
* Message output should not interfere with the normal operation of the robot, nor with the user's interaction with the computer interface, if it is assumed that the user may work in parallel with the robot.
* It is permissible not to display messages in cases where the actions, stage, and progress of the robot's work are completely obvious from what is happening on the screen.
* Logged messages should answer the following questions: "What is happening now?", "Is everything going according to plan?", "How soon will this be finished?" or "How quickly is the specified workload being processed?"

8. **Recommendations for Storing Source Files.**

All source files of all robots should be saved in a GitHub account. A sub-repository will be created for each developer's project, to which the executor will have access.