Send Partner Portal Reference¶

The Send Partner Portal is the self-service system for requesting all non-local deployments and operations on the Send Workbench platform. It is built on Jira and provides a structured form for each type of request, ensuring the right information is captured and routed to the right team.

Portal URL: https://send-partner-portal.refined.site

Official Send documentation: https://partner-docs.sendtooling.com/

When to use the portal¶

Every deployment outside your local PDE environment goes through the portal. You do not email DevOps or raise ad-hoc Jira tickets — you use the portal forms. This ensures requests are tracked, prioritised, and have a clear audit trail.

Local (PDE) development does not require any portal requests — you manage your own Docker Compose stack.

Request types¶

Client Build & Deploy¶

Use for: Deploying a branch to the Dev environment.

Dev deployments are branch-based — no version tagging is needed. You specify the branch to deploy and the portal handles the rest. Expect approximately 6–10 minutes of downtime during the deployment.

What to provide: - Client name - Branch name to deploy

Create Client Microservice Version¶

Use for: Creating a tagged version of the client microservice, ready for deployment to SIT or UAT.

This must be done before a Deploy Client Microservice Version request. The version tag is what gets deployed — it locks in a specific state of the codebase and config.

What to provide: - Client name - Branch or commit to tag - Target environment (SIT or UAT)

Deploy Client Microservice Version¶

Use for: Deploying a tagged client microservice version to SIT or UAT.

This is the second step after creating a version. Always deploy DynamoDB changes (if any) before raising this request.

Deploy DynamoDB first

If your deployment includes changes to dynamodb/{env}/data.json, raise a Deploy DynamoDB Changes request and confirm it has completed before raising this request. Deploying the microservice with an incompatible DynamoDB profile causes startup failures.

What to provide: - Client name - Version tag to deploy - Target environment (SIT or UAT)

Deploy DynamoDB Changes¶

Use for: Deploying changes to dynamodb/{env}/data.json for any non-local environment (Dev, SIT, or UAT).

DynamoDB changes require a service restart to take effect. The restart is handled as part of this portal request — you do not need to raise a separate restart request.

What to provide: - Client name - Target environment - Summary of what changed (helps the team verify the deployment succeeded)

Workbench Core Deployment¶

Use for: Deploying a new version of the Workbench core platform.

This is distinct from the client microservice — the Workbench core is the shared platform that all clients run on. Core deployments are typically managed by Send, but the request type is available if a specific core version is required for a client environment.

Workbench Restart¶

Use for: Restarting services in an environment without deploying a new version.

Use this when you need to pick up configuration changes that require a restart but no new code or DynamoDB changes have been made.

Create Client Hotfix¶

Use for: Initiating an urgent fix for a production issue that cannot wait for the standard promotion path.

The fix branch must be prefixed with hotfix/ (e.g. hotfix/fix-sanctions-routing). The hotfix bypasses the standard Dev → SIT → UAT promotion cycle.

After the hotfix is deployed to production, back-merge the hotfix branch into uat, sit, and dev immediately to prevent drift.

What to provide: - Client name - hotfix/ branch name - Description of the issue being fixed

Create Core Hotfix Version¶

Use for: Initiating an urgent fix to the Workbench core platform.

This request type is for Send engineering use — client configurators should not normally need this unless directed by a Send technical lead.

Deploy Core Hotfix¶

Use for: Deploying a core hotfix to a target environment.

Again, this is primarily a Send engineering request type.

Typical deployment flows¶

Deploying to Dev¶

1. Push branch to config repo
2. Raise: Client Build & Deploy (specify branch)
3. Wait ~6-10 min for deployment
4. Validate in Dev environment

If DynamoDB changes are included, also raise a Deploy DynamoDB Changes request (order does not matter for Dev — either can go first).

Promoting to SIT or UAT¶

1. Merge to the target branch (sit / uat)
2. If DynamoDB changes: raise Deploy DynamoDB Changes → wait for completion
3. Raise: Create Client Microservice Version
4. Confirm version tag has been created
5. Raise: Deploy Client Microservice Version (referencing the version tag)
6. Validate in the target environment

The DynamoDB-before-microservice ordering is critical for SIT and UAT — see the warning in the Deploy Client Microservice Version section above.

Raising a hotfix¶

1. Create hotfix/ branch from main
2. Apply fix and push
3. Raise: Create Client Hotfix
4. Validate fix in production
5. Back-merge hotfix/ into uat, sit, and dev