Need of service account in Appian

Service accounts are typically used to authenticate with Appian web APIs. They are created when making API

keys docs.appian.com/.../Appian_Administration_Console.html

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.

How to Authenticate the API using a service account user? How do I test my API?

Hi @Shikha,

Check the link below to understand how you can leverage your service account

docs.appian.com/.../Web_API_Authentication.html

From the Web API object, you can provide test inputs to test the output. You can also use an application such as Postman to test REST apis with the API key, just look at the documentation to make sure you provide the correct headers.

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.