Hi Roshan,

I hope I can clarify things a bit.

• BPT works with a queue of eligible activities (i.e. activities that are allowed to run). Activities can run concurrently, with a maximum of 10 at a time (by default, it's possible to increase this) . It is not known exactly how the scheduler schedules the activities, but in general it makes sure that all activities are processed in due time (but of course, if you have 1000s of activities, it may take a while before all activities have run);
• If an activity results in an exception, the activity gets an Error status. Activities that have this status are retried by the scheduler. The Platform keeps an error count for an acitivity, so it knows how many times a certain activity has resulted in an error. The higher the error count is, the more time it will take before the scheduler retries the activity. If an activity has 10 errors already, it may take a day for the next retry (exact details unknown).

From the above, we can deduce that a few errors do not seriously impact the BPT performance. But if you have a high percentage of errors, all these errors are retried periodically, so will have some impact. Note that errors do not typically impact the time other activities are running. It doesn't typically matter whether an activity is running that had an error previously, or is generating an error, at the same time as another activity is running - they should run independently (of course, if an activity is blocking database access with a GetForUpdate, then performs a long REST or database call, it could effect other activities running, but in that case you have a badly designed activity).

As for the suspended processes, they are most likely the result of an impact analysis after deployment of a BPT process flow that was altered in such a way, that running instances could no longer run. I'm not too well versed in this part of BPT, so I can't really help you there.