Data Sharing permissions
Uber minimizes data storage, fetching only the necessary information for e-receipt forwarding or roster sync while maintaining strict data privacy and transparency.
¶ 1. Employee Roster Sync Architecture
Ingestion Lifecycle and System Flow
-
Initiative: The roster synchronization model is strictly pull-based and unidirectional (Concur to Uber). Uber initiates all data transfer requests.
-
API Dependencies: System orchestration relies on concurrent calls to the SAP Concur Identity Search API (v4.1) and SAP Concur Spend API (v4.1).
-
Sync Triggers:
-
Initial Onboarding: Client’s full concur roster is fetched into Uber’s secure staging layer to enable the setup experience where customers (admin) can choose specific employees or apply desired filters to finalize their roster sync configuration. Once confirmed the actual sync of the selected employees will get initiated. Any data associated with the remaining employees who are not selected for synchronization is automatically deleted within 48 hours from Uber’s secure staging layer.
-
Maintenance Cycles: Automated data synchronization cycles run every 6 hours (4 times daily) to capture employee additions, updates, and removals. Therefore, any changes made in SAP Concur may take up to 6 hours to appear in the Uber for Business dashboard.
-
Post-Ingestion Data Minimization and Staging
Uber fetches the entire employee payload exposed by the client’s upstream Concur configuration. Strict privacy limits are enforced via a decoupled, multi-tier data pipeline:
-
Secure Staging Layer: The incoming raw payload is initially stored in a temporary, isolated staging database layer.
-
Post-Fetch Filtering: Uber applies the attribute filters configured by the administrator. Only records that meet these exact parameters are written to the persistent production database to manage active U4B dashboard users.
-
Automated Purge Safeguard: Unselected custom attributes, unused address rows, or profiles belonging to non-syncing employees are held strictly in temporary staging. This unselected data is automatically and permanently deleted from the staging layer within 48 hours (2 days) of ingestion.
¶ 2. E-Receipt Forwarding Architecture
When organizations enable automatic e-receipt forwarding without Roster Sync, Uber functions exclusively as a secure transactional data forwarding service.
Billing Configuration Boundaries
The receipt ingestion mechanism is restricted strictly to a decentralized billing model. Automated receipt matching fails and is blocked for any transactions flagged under centralized billing configurations.
¶ 3. Comprehensive Data Governance Summary
| Active Feature Scope | Data Fetched from SAP Concur (but not persisted at Uber) | Data Stored at Uber | Storage and Retention Policy Details |
|---|---|---|---|
| E-Receipt Forwarding Only | None | None | Zero data ingestion occurs from SAP Concur. Uber acts purely as an outbound transactional data service. |
| Employee Roster Sync Active |
|
|
|