Background: We do not use tempo or user tasks in our application. All our objects are deployed to higher environments under a service profile.
We are having a discussion on best practice for swim lane assignments, here are the two thoughts:
1. All swimlanes should be set to run as designer.
2. All swimlanes should be set to run as initiator unless elevated privileges are needed.
I'm in camp #2. I don't believe process models should be set to run as designer. Our service profile has Appian Admin access and therefore should only be used on a limited basis.
While I'd like to hear opinions on this, if anyone has links to Appian recommendations, that would be even better. Seems like "best practice" is thrown around too freely without official documentation and based more on personal preference.
Thanks
Discussion posts and replies are publicly visible
I'm not aware of (and had a quick look and couldn't find anything) any explicit best practice documentation for swim lanes. Depending on overall design of your platform the differences between the two options are fairly minor. I personally subscribe to camp #1 (but not strongly) and rely on process model security for access. I'd be interested to hear about a scenario where running as designer resulted in an unintended result (or access granted where it should have been denied) but I've run option# 1 for years and have not run into any issues.
Camp #2 has caused issues but they were minor and as a result of very long lived legacy process models where the initiator had been deactivated in the environment. Good design circumvents option# 2 resulting in issues though.
In the past I've also utlised multiple swim lanes (Eg. An initiator and a system swim lane) where I used both options but as only the User Input Task or Start Node (with form) was in the initiator swim lane it was essential camp# 1 in practicality.
There is of course a camp #3 being assigning all nodes in the swim lane to a person or group of people (likely role based assignment); but I've never used this option.
I daresay this isn't the definitive response you hoped for but I'd be keen to hear others input.
Thanks. I understand the point on #2 about long running processes. All of our processes are short lived. None last over an hour without automatically timing out. Our application has been running using the 2nd method for over a year and half with no issues. But now, there are some who want to switch all the process models over to method 1.
On method 1, I don’t see it breaking anything necessarily. But a couple of possible issues come to mind.
a. The designer in our production environment is an Appian Admin. So now processes are running needlessly with elevated authority. Which sounds like a way of not addressing proper security setup. If this was the intent, why does Appian even have the other option available.
b. If a Subprocess call is not overridden. In the process monitor it will appear as though the service profile is running it. Which could make production support a slightly more difficult when trying to track down an issue.
Your 3rd camp is interesting, but seems tedious if the process model has lots of nodes that need to be configured the same way. Seems like the swim lanes help give a “default” value.
Thanks for your input. I’m fine with changing things if there is a reason. But in this case, it seems like a way to potentially avoid an error that a user should be getting if a developer inadvertently setup a process to run a process that the user was not really authorized to use. As Stefan mentioned in his comment, I’m in the camp of keeping security tight and only elevating when necessary.
Good conversation!
In principle I definitely agree that security should be set to be as low as possible. I believe the way I've been using Camp# 1 is basically the same as not using swim lanes at all as it is extremely rare that I use "User Input Tasks".
My process models are generally short lived like yours (there needs to be a very good reason to have something open for more than an hour) and start with the form in start node. My "Tasks" are generally based off the database and not an in-flight "User Input Task".
It seems the security options within process models are there for both legacy reasons and to allow flexibility in design.
I think I could delete my swim lanes and nothing would change!