Created a new Service Account in the Admin Console and generated API Key. Added the new Service Account to a security group that has access to an application. Added the updated security group to a patch and deployed it to the next higher environment (AFTER creating the same new Service Account in that higher environment - since the API Keys are different), but after import - the new Service Account was not included in the security group. According to the documentation, it should be. "API keys and service accounts can be managed in the Admin Console by system administrators. Service accounts should be created in each environment with the same username and placed in the same groups so that permissions can be promoted to higher environments. API keys can only be used for the environment they're created in." I'm assuming that we will have to manually add the Service Account to the security group in each higher environment - but why? The name of the Service Account created IS the same in both DEV and TEST - as is the description. After creating them - they both were added to the Service Account group - as described in the documentation.
Discussion posts and replies are publicly visible
Service accounts should be created in each environment with the same username and placed in the same groups
Actually, this implies to me (without further clarification at least) that the service account *does* need to be manually placed into the appropriate group in each environment.
But the next sentence implies that once the it is in the same group - that group can be promoted to higher environments.
"so that permissions can be promoted to higher environments"
To me it seems as though If I create ABC.Service (as a new Service Account) in each environment and add it to GroupXYZ in DEV, when I create a patch in DEV with this updated group and import it into TEST (where ABC.Service already exists) - GroupXYZ in TEST should include ABC.Service. I shouldn't have to manually add it to the group.
that group can be promoted to higher environments.
My reading of it was that the group / "permission" is promoted, not actually the account, though I do see where you're coming from. I don't have much experience yet with this new service account construct, all I know is that traditional user accounts are never transferred between environments. Hopefully someone with more detailed technical knowledge about this new functionality can weigh in as well.
You may be right - If I had included the Service Account group and promoted it that way- It would have included the user but because this new Service Account is a 'user account', it is likely that it needs to be added manually. I didn't really think of the Service Account as being like a user account but I suspect that's the case.
You're right, Judy: Service Accounts are still basically user accounts first. When a user is added to the Service Accounts user role (group), it becomes a service account.According to current product functionality, user accounts must be created in each environment where they are to be used. They cannot be moved from one environment to another like other Appian objects.When a group object is exported from a system, member users are not also exported.
© 2020 Appian. All rights reserved.