Automated activity context best practice

I think having to use "run as designed" to often shows bad design. It means to overrule any security that is in place. It is the same as working as an administrator or root on your PC.

I tend to agree with your premise. This is the guidance I've provided my developers, but haven't found any documentation to back that up.

However, if it is a smart service (i.e., Send E-Mail...from the process, or news feed), or a 'Write to Data Entity' node - wouldn't it be best to assign it to 'Run as whoever designed the process' vs 'Run as whoever initiated the process'? I recently ran into an issue with this setting. Once I changed it (on the Email node) to 'Run as the designer', it worked just fine. Because the initiator was the person who started the initial process and this node was met along the way - the process failed (I received an 'InvalidUserException' error).

Judy, I was reading your post. Getting security right in Appian is tough and you need a lok of experience. But having good security in our applications is absolutely crucial. So we have to find our way ...

I think disabling security is wrong. Running a node as an admin user is just wrong 99,9%. The last .1 percent is for experienced Appian designers and has to be discussed in the dev team.

How would you avoid the error I got if I kept the assignment as it was? If the node is associated with a 'system' action such as writing to a data entity or sending an email from a process, doesn't it make more sense to run it as the 'admin' - the designer? I wouldn't suggest making this the default on all the smart services (and certainly wasn't suggesting disabling security), but for smart services that are generally launched by the system (another one might be a subprocess node) - it seems to make more sense to me to run it as the 'designer' vs process initiator.

In Appian everything runs in a user context. Be it the initiator or the designer. By best practices, the designer will be a special administrator type deployment account, only used to deploy applications to the environment.

By staying inside the initiator context you make sure that the process can only do things its initiator could do. As I said. Doing security right is hard work, and running nodes as admin is no general solution.

I figured out why I received an 'InvalidUserException' error at the 'Send Email' node. The privacy setting for one of the groups in the recipient list was set to high. I did some more research and read that if you set the assignment for this node to 'Run as whoever started the process', the initiator has to be able to see the members in the group. Because the privacy setting on one of the groups was 'high', the initiator couldn't see those members and therefore, did not have the authority to send an email. Note that if the setting IS changed to 'Run as whoever designed the process', the recipient group needs to be publicly visible or the designer has to be a member. As for setting the assignment to 'Run as whoever started the process' for a 'Write to data entity' node, the initiator must be in a group that has viewer rights to the Data Store.

Great you solved your issue. Group security is always a joy ;-)