> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tangoanalytics.com/llms.txt
> Use this file to discover all available pages before exploring further.

# User provisioning nonbu file

# Tango User Provisioning (non-BU) — File

> Generated from `Tango User Provisioning Integration Design Specification_non BU V1.4.docx` in SharePoint folder `01 Common Integrations`.
> OAS spec: [`user-provisioning-nonbu-file.yaml`](./user-provisioning-nonbu-file.yaml)

## Overview

SFTP file-based inbound for clients without a Business Unit layer. Client drops a **JSON** file (note: not pipe-delimited like other Tango file integrations) on Tango's SFTP server; Tango processes the file and creates / updates / inactivates user accounts.

**Owner:** Tango Analytics
**Spec version:** 1.4
**Status:** Draft (auto-generated — needs review)

## Transport

| Attribute | Value |
| - | - |
| Direction | Inbound (Client → Tango) |
| Mechanism | SFTP file drop |
| **File format** | **JSON** (.json) — different from other Tango file integrations which use pipe-delimited .txt |
| File naming | `{ClientCode}_user_prov_non_bu_MMDDYYYYHHMMS.json` |
| Production host | `sftp.tangoanalytics.com` |
| Test host | `sftpdev.tangoanalytics.com` |
| Path | `/inbound/User_Provisioning` |
| Auth | SFTP user/password (TBD) |
| Frequency | TBD |

## Integration logic

Same as the API variants:

* New user → create.
* Existing user → update.
* `status = N` only → inactivate (other fields ignored).
* GENERAL\_USER → only `first_name`, `last_name`, `email`, `user_type`, `status` honored; SSO always enabled.
* `Country = ALL` → access to all countries in the Brand/Region.
* Inactive users cannot be created from scratch.

See [`user-provisioning-nonbu-api.md`](./user-provisioning-nonbu-api.md) and [`user-provisioning-bu-api.md`](./user-provisioning-bu-api.md) for the detailed integration logic — this file integration shares all semantics with the API variants, only the transport differs.

## Data model

Same shape as the [non-BU API spec](./user-provisioning-nonbu-api.yaml):

* Root: `{ "records": [ <UserRecord>, ... ] }`
* `UserRecord`: user\_name, first\_name, last\_name, email, user\_type, sso, status, title, location, default\_country, default\_brand, data\_access\_level, brands\[]
* `BrandAssignment` (no business\_unit): brand\_name, country, region, roles, entity\_security\[]

Required-field rules and value enums (A/N, Y/N, F/R/RR, CORPORATE/CONTRACTOR/GENERAL\_USER) are identical to the API variants.

## Open Questions / Assumptions

* [ ] **File format is JSON, not pipe-delimited** — this is the only Tango file-based integration in the suite that uses JSON. Confirm the wrapping (single object with `records[]` per the sample) and whether the file may contain multiple `records[]` blocks or just one.
* [ ] **SFTP credentials** are `<TBD>`.
* [ ] **Timing/frequency** is `<TBD>`.
* [ ] **`default_business_unit` field appears in the source's Integration Logic** ("User access to brands, business units, countries, and regions will be assigned based on the client's environment setup") even though this is the non-BU spec. Likely copy-paste from the BU variant — confirm `default_bu` is genuinely absent here.

## Changelog (compressed)

| Ver | Date | Description | Author |
| - | - | - | - |
| 0.1–1.3 | 2021-2024 | (see source doc — 14 revisions) | Various |
| 1.4 | 03/17/2025 | Updated User Inactivation logic | Rahma Ouedraogo |