Granting Access for a New Offshore Team

Start from least privilege and separate build, test, and operate. In development, the partner needs to create and edit processes and objects, so grant a build role scoped to the development environment: create and edit process and object, run in development, and use the credential and queue features needed for build testing. They should not have release rights or schedule-change rights there, because those affect other environments.

In UAT, the partner needs to run and debug but not to alter the released package. Grant a test role that permits running processes, viewing logs and queue items, and resetting test queue items, but not editing the released process or changing schedules. This also limits their view of data: UAT should hold masked or synthetic data so the partner never sees live customer records, which addresses the security concern directly rather than relying on role restrictions alone.

In production, only the 2 support leads should have any access, and it should be an operate role: view sessions, logs, queues, and schedules, and restart sessions, but not edit processes, release packages, or change schedules. Production releases remain with the internal change board, so the partner prepares a package and the internal team releases it after approval. Each grant maps to a task the partner must perform; anything else is denied by default.

Releases: the partner should build and package in development, promote to UAT through the internal release process, and submit to the weekly change board for production. The board should require evidence - test results, a rollback plan, and confirmation that no credentials or environment-specific values are baked into the package. The partner should not hold the release permission in production at all; separation of duties means the builder cannot be the releaser.

Credentials: the partner's developers should be able to reference credentials in development but not read them. Use the platform's credential store with access restricted so that values are never exposed in logs or in the process. Production credentials should be accessible only to the runtime resources and the support leads' operate role, and any credential change should be logged and reviewed.

Periodic review: run a quarterly access review listing every partner user and their roles per environment, with the partner manager and the internal owner both signing off. Remove access promptly when a developer leaves the engagement. Review logs for anomalous activity, such as failed permission attempts or out-of-window production logins, and review the support window adherence monthly. Finally, document the access model and the review cadence in the engagement agreement so the controls are contractual, not informal.

Decline the shared account. A shared login destroys accountability: logs would show one identity for eight people, so an incident could not be traced to an individual, and access reviews could not tell who still needs access when someone leaves. It also makes revocation impossible without disrupting the whole team, and it usually violates the audit requirements the security team is applying.

Provide named accounts for each developer, mapped to the roles designed above, with the 2 support leads holding the additional operate role for production. Automate onboarding and offboarding so accounts are created and disabled as people join and leave. If the concern behind the request is convenience, address it with single sign-on or a provisioning process rather than a shared identity. If the concern is licence cost, discuss named-user licensing with the vendor rather than compromising auditability. The response should be firm but offer a workable path, so the partner can operate without the shared account.