Deployment of first solution on-premise

One thing we learned a little late (years ago) was to use your system account if possible. When you import new objects they are 'created by' the user that performs the import, since many of the security related functions and logic (a process calling a subprocess) depend on it running under the context of whomever created the object or process this keeps them consistent. Also, if each developer imports to production over time using their accounts not only can this cause issues with security (i.e. developer C has lower/higher rights in the future than when they imported) the code may either not work at all or give too many rights) but the accounts used to import can never be deactivated. If you deactivate the user the applications may loose their security context...so if you buy X licenses in Appian and 10 people over time import to Prod you essentially have used 10 accounts in perpetuity.

We now try and consistently import into our QA & Prod environments using a system account. In Windows, we hold the shift key and right click on Internet Explorer, select 'Run as different user' and then enter the credentials for the system account. Connect to Appian and (login again) import. Then, in theory at least, all objects when created are owned by that 1 account. Updates to existing objects generally don't have to be done this way, but we try to do so as a good practice since your import package likely has at least 1 new item in it. This also benefits because the system account then gets Alerts (at least in our environment) in addition the individuals that you configured in the process models.

One thing we learned a little late (years ago) was to use your system account if possible. When you import new objects they are 'created by' the user that performs the import, since many of the security related functions and logic (a process calling a subprocess) depend on it running under the context of whomever created the object or process this keeps them consistent. Also, if each developer imports to production over time using their accounts not only can this cause issues with security (i.e. developer C has lower/higher rights in the future than when they imported) the code may either not work at all or give too many rights) but the accounts used to import can never be deactivated. If you deactivate the user the applications may loose their security context...so if you buy X licenses in Appian and 10 people over time import to Prod you essentially have used 10 accounts in perpetuity.

We now try and consistently import into our QA & Prod environments using a system account. In Windows, we hold the shift key and right click on Internet Explorer, select 'Run as different user' and then enter the credentials for the system account. Connect to Appian and (login again) import. Then, in theory at least, all objects when created are owned by that 1 account. Updates to existing objects generally don't have to be done this way, but we try to do so as a good practice since your import package likely has at least 1 new item in it. This also benefits because the system account then gets Alerts (at least in our environment) in addition the individuals that you configured in the process models.