AgilePoint NX as a product is used by companies with employees ranging from 50 user – 400K users. A lot of organizations do a global roll out of AgilePoint NX for their employees worldwide with application designers spread across multiple continents.
A lot of global roll-outs do involve SharePoint integration and a question we sometimes come across is around the best practices on how admins can manage the access tokens specially when each country/department might be using their own set of SharePoint site collections. Though I am using SharePoint here an an example, the same concept would apply for other systems like a database.
Now typically if you are a smaller org with limited roll out to few departments only and limited set of designers, the strategy of using global level access tokens works better as you create connection once and let all designers use the same token. This can certainly be locked down to certain users or groups if required which I had covered in my other blog post.
Restrict workflow activity and form lookup usage to certain users in AgilePoint NX
However if you are an admin for a global company which is doing a global roll out of AgilePoint with designers spread across multiple countries and designing hundreds of department level workflows, a single global access token approach might not be ideal fit for your organization. Application level access token in much more relevant than global app token for such organizations. You do not want to create a global token with all permissions and open to all designers this way in a big organization.
I would recommend lock down global tokens for very specific apps using the permission control shown in the blog post mentioned above and assign them to specific users or groups only typically used for admin level workflows. For most apps, better depend on application level access token as a best practice which gets moved across from one environment to other along with the app itself but you still have an opportunity of changing the account used in production. That would be best practice for global deployments.
While deploying application from development to production, big organizations would usually want to follow best practices that only config management team can move the apps into production. So in development environment, designer could use whatever account he wants in the app level access token, but when you move the app to prod with help of configuration management team or admins, admins change account in app to service account the first time app is deployed. Remember, this is only one time thing as once app is deployed and if you keep moving new versions of app in future, it won’t overwrite already existing app level access tokens unless you create new one. We have best practices already baked into the app deployment module that it won’t overwrite already existing app token everytime else everytime admin would have deployed a new version you would have incurred an admin overhead. The only time after initial deployment admins need to change anything in app tokens is if a new access token is defined. So it will follow all best practices and lock down the security to something which is controlled by admins which are moving the apps to production else it can get out of hand if hundreds of users are deploying apps to production directly.
This will be 100% secure and you do not end up creating just all-inclusive access token for all designers and give them ability to perform actions on sites which otherwise they were not even allowed to access in their country or department. Access token would be scoped at site collection level as you do not want users to see more than they should.
Now another common question we get is that can we create app with app level access token and same token can be configured so that the same app works across multiple site i.e. reusable workflow, that is already supported and I had covered this in my other blog post
To summarize, if a global client is creating multiple department level workflows which are being designed by people spread across globe, creating just one access token for everyone is not a good design. Keep global tokens for limited use and for limited set of users like admin workflow. In general use app level access tokens and for reusable apps, use app level access token which is configured for connecting to multiple site collection at runtime.