Need of service account in Appian

In addition to what Danny already mentioned, it's also very useful to set up service accounts to handle incoming automated deployments between environments.  Such users would be created separately and then added to the Service Accounts group.

Hi Mike ,

In what way setting up of service account is beneficial from deployment perspective ? How’s it different?

Back in the old days prior to automated deployments and service accounts, when you deploy to production you'd have to do it as a regular user - sometimes you could create a special admin login to do this, but in certain cases (clients with strict SSO requirements for example) this was either very difficult, or impossible.  That meant deployments would need to be run under the name of a real user, normally a developer. 

This started causing huge issues when a developer rolled off a project and their account was deactivated, etc.  I ended up spending hours creating a process that would iterate through all process models in a system and re-publish them under a fake system account.  And even then, this system account would need to be logged-in every so many days or else it would be automatically deactivated under their inactive account policy - there was no way to except any particular users from this.

When they implemented the Automated Deployment system, we were able to set up the prod environment to publish incoming deployments under the account we wanted to, but it was still a "regular" user and subject to being deactivated if it wasn't logged-in by someone every X days.

Then they implemented service accounts, we were able to finally get over this last hurdle by simply making that special user a Service Account, meaning they never need to log in, and will never get deactivated.

Back in the old days prior to automated deployments and service accounts, when you deploy to production you'd have to do it as a regular user - sometimes you could create a special admin login to do this, but in certain cases (clients with strict SSO requirements for example) this was either very difficult, or impossible.  That meant deployments would need to be run under the name of a real user, normally a developer. 

This started causing huge issues when a developer rolled off a project and their account was deactivated, etc.  I ended up spending hours creating a process that would iterate through all process models in a system and re-publish them under a fake system account.  And even then, this system account would need to be logged-in every so many days or else it would be automatically deactivated under their inactive account policy - there was no way to except any particular users from this.

When they implemented the Automated Deployment system, we were able to set up the prod environment to publish incoming deployments under the account we wanted to, but it was still a "regular" user and subject to being deactivated if it wasn't logged-in by someone every X days.

Then they implemented service accounts, we were able to finally get over this last hurdle by simply making that special user a Service Account, meaning they never need to log in, and will never get deactivated.