Process Model Lane Assignments

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.

When you do not use "User Input Task" nodes, why bother with swim lanes and assignment in the first place?

In my opinion, security should be as tight as possible and only elevated if necessary.

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.

I don't use swim lanes at all until and unless I have a specific reason to use them.  Usually this is involving task assignments which would need to remain consistent in a lane, and sometimes it's more about visual flow organization (though that can turn into too much of a pain in the butt very quickly).  In the latter case, which sounds like it applies to you, I don't see any particular reason to set any lane-specific permissions.

Same here ...

I'll use swim lanes regularly, but not often for node assignments.  Mostly just for a visual in /design.  Especially with Tempo/SAIL, it's much less common these days that I have to chain tasks for the same assignee or route a process back to a different task for the same assignee (multiple nodes in a lane with the same assignment).

The only lanes I might use for assignment are System lanes with chunks of unattended nodes, for which I do assign these to the process designer, mainly for the case AJ notes with process initiator accounts becoming deactivated.  This has caused us a lot of support in the past, for which each process instance is just edited and changed to run the node as designer anyway..

My security is always controlled outside of the node assignment settings.

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!

In my opinion the security should be set to run as the designer. In other environments the user that does the deployment takes the role of the designer. This means that if the security is set to the designer and a generic technical user is used for the deployment  then the process model will be executed with the service account and you will avoid problems that you would have if the security is set to the initiator.

If the security is set to the initiator then problem comes the day the initiator user leaves the company and becomes and inactive user. All the in flight process would then fail. That will not happen if you set the security as the designer and you use a service account to deploy to other environments.

Additionally I am curious to know why some people is suggesting not to use swimlanes unless they are needed. Is there a benefit of not using swimlanes? My view is that even in a process with no Human Tasks you might want to update the security one day to one configuration or another, or you might want to check what is the security of a process. It is much simpler and faster to do that at the swimlane level (once) rather than node by node. So I still see a benefit of a single System swimlane, but at there are disadvantages?

IMHO, any node should be run with the lowest level of privileges possible. But I think there are to many topics mixed up in this thread.

Stefan, it is also a good way of thinking. There might be a few valid views. I usually set the security of all the standard nodes to Run as the designer in one swimlane and deploy the packages with a service account. If something needs special security settings I create another swimlane for that. I find it more visual and easier to maintain. I am used to work with swimlanes even if there is only one actor involved and I see no problems there but I will be happy to learn better approaches.