Organization Structure

The Organization Structure feature provides a standard, scalable way to model your business inside DataServ. It defines how documents, security, and integrations are aligned to the way you actually operate (regions, entities, operating units, locations, and ERP(s)).

By using Organization Structure, you can:

• Route invoices and other documents correctly based on where they belong in your business

• Align DataServ with one or multiple ERPs

• Apply consistent user security

• Support more flexible reporting and integrations

This article explains how to:

• Understand the Organization Structure model

• Know when and why you should use it

• Understand how it impacts user security and documents

• Prepare for multiple ERPs and integrations (including the DataServ API)

• Take next steps to set up or update your structure in partnership with DataServ

Note: This article is focused on concepts and admin workflows. Technical implementation details (file formats, APIs, etc.) are handled by DataServ as part of a project and will be coordinated with your Client Success Account Manager (CSAM) and/or DataServ Support.

Who Should Use this Guide

This guide is intended for:

• DataServ administrators who manage configuration, security, and client setup

• IT / ERP owners and integration teams who need to understand how Organization Structure ties into data feeds, APIs, and multiple ERPs

What is the Organization Structure?

The Organization Structure defines a hierarchy that DataServ uses to categorize and secure documents:

1. Organization 
   Your overall company or client in DataServ (top of the hierarchy).

2. Region 
   A major grouping such as geography or business segment (e.g., “North America”, “EMEA”, “Retail”).

3. Entity 
   A legal entity, company code, or business unit within a region.

4. Operating Unit 
   A sub-division or operating grouping within an entity (this often aligns to how your ERP organizes operations, such as an Oracle Operating Unit or SAP Division).

5. Location 
   A physical or logical location such as a site, store, plant, or office.

At each level, DataServ can also track ERP-related attributes (such as ERP name, ERP type, and inbox details) so that documents and integrations are correctly associated with the right ERP.

Internally, each of these elements has both:

• A client-facing label (the name you see in the UI), and

• A stable internal ID used for security and data integrity.

Renaming labels will not break security or historical data, because access is based on IDs, not names.

Why Move to the New Organization Structure?

The new Organization Structure is the foundation for a number of capabilities:

• Consistent security and access control 
  Users are granted access based on combinations of Region, Entity, Operating Unit, and Location. This ensures that users only see documents for the parts of the business they are responsible for.

• Cleaner multi-ERP support 
  When you have multiple ERPs, your structure can reflect which parts of your organization are tied to which ERP. This allows DataServ to route data correctly and keep coding and master data aligned.

• Better document data and reporting 
  Each document can carry Region, Entity, Operating Unit, Location, and ERP metadata, improving traceability and reporting.

• Modern integrations, including the DataServ API 
  For new API-based integrations, clients must be on the new Organization Structure. This ensures that data being sent/received is correctly tied to your business hierarchy and ERP(s).

Prerequisites

Before using or changing Organization Structure, ensure:

1. Feature enablement

   • Your organization has the Organization Structure feature enabled by DataServ.

   • If you are not sure, contact your CSAM or DataServ Support at support@dataserv.com.

2. Admin access

   • You have the appropriate Configuration / Admin permissions in DataServ to view and maintain Organization Structure–related settings, user security, and lookups.

3. ERP considerations

   • You understand how your ERP maps to your regions/entities/operating units/locations.

   • For multi-ERP setups, you have a clear view of which parts of your organization belong to each ERP.

4. Data model planning

   • You have a high-level hierarchy agreed internally:

     • What are your Regions?

     • How are Entities grouped?

     • How should Operating Units and Locations be defined?

   • You have identified any existing codes / IDs (e.g., region codes, company codes, location IDs) that should be used as client-provided IDs within DataServ.

How Organization Structure Works in DataServ

The hierarchy and IDs

At each level (Region, Entity, Operating Unit, Location), DataServ maintains:

• A unique internal ID (used for security and document linkage)

• A client-provided ID (such as your ERP company code or location code)

• A name / description

• An active flag (active vs. deactivated)

• Optional ERP attributes, such as:

  • ERP Name

  • ERP Type (e.g., Oracle, SAP, Dynamics)

  • Inbox and Inbox Type (for routing)

This design allows:

• Safe renaming of labels without breaking user access or historical data

• Deactivation of obsolete structure elements while still preserving historical documents

• Assigning different parts of the structure to different ERPs when needed

Organization Structure and User Security

User security is based on Organization Structure IDs, not labels. This ensures stable access even when names change.

Assigning security

At a high level:

1. Each user is assigned one or more combinations of:

   • Region ID

   • Entity ID

   • Operating Unit ID

   • Location ID

2. A user only sees documents that match one of the combinations they’ve been granted.

3. You can assign a user to “ALL” at a given level of the structure:

   • If “ALL” is chosen at one level, you cannot pick specific lower-level values at that same branch.

   • “ALL” includes deactivated children in the structure, so access to historical documents is preserved.

4. Some security groups (e.g., Confidential Vendor, DMQA, Document Retention) respect the same Organization Structure assignments and only extend access within the portions of the structure the user is already entitled to.

5. Vendor Portal users:

   • Are limited to the Vendor(s) they are assigned, and

   • Are further restricted by their Organization Structure access.

What this means for administrators:

• Users cannot see or interact with documents outside the Organization Structure areas they are assigned.

• Changes to labels (e.g., renaming an Entity) do not require updating user security because it is based on IDs, not names.

How Organization Structure Appears on Documents

Once the structure is configured:

• Documents in DataServ will carry Organization Structure fields, such as:

  • Region / Region ID

  • Entity / Entity ID

  • Operating Unit / Operating Unit ID

  • Location / Location ID

  • ERP (derived based on the structure and configuration)

Implications:

• Search and filtering can use these fields to locate documents by business area.

• Analytics can be aggregated at Region, Entity, Operating Unit, or Location level.

• Security automatically filters results based on the user’s assignments.

Organization Structure and Multiple ERPs

If your organization has multiple ERPs, Organization Structure is how DataServ keeps them organized and separated.

Key points:

• Multiple ERPs is an optional capability that can be purchased.

• ERP is influenced by but not strictly a child of the Organization Structure – it is configured in a way that allows:

  • Different parts of the structure (e.g., different entities or locations) to be tied to different ERPs.

  • Correct routing of inbound and outbound data for each ERP.

• Configuration allows:

  • Tying data loads and extracts to an ERP.

  • Automatically pulling the right coding data based on ERP settings.

From a client / administrator perspective:

• Work with your CSAM and DataServ implementation team to define which parts of your Organization Structure are associated with which ERP(s).

• This will be reflected in how data is loaded, routed, and returned between DataServ and your ERPs.

Organization Structure and the DataServ API

The DataServ External API assumes that your organization is on the new Organization Structure model.

• For existing clients:

  • If you are migrating from SFTP datafile batch processes to the API for a given ERP, that ERP must be fully moved to the API.

  • The Organization Structure for that ERP must already be configured in DataServ.

• For new clients:

  • Organization Structure and API integration are typically set up as part of your initial implementation.

If you are planning to use the DataServ API, let your CSAM or DataServ Support know so that API considerations are included in your Organization Structure project and in your onboarding activities.

Best Practices

• Keep the structure aligned to your ERP(s) 
  Use existing ERP concepts (company codes, operating units, locations) where possible to simplify mapping and integrations.

• Use stable IDs and logical names 
  Store your ERP / organizational codes in client-provided ID fields and use descriptive names for admins and end users.

• Plan ahead for security 
  Design your Regions/Entities/Operating Units in a way that naturally maps to how user access should be segmented.

• Deactivate, don’t delete 
  When parts of your organization are retired (e.g., merged or closed locations), deactivate them so historical documents remain intact and accessible (according to security).

• Coordinate multi-ERP changes with DataServ 
  Because multi-ERP configurations touch data flows, coding, and structure, work closely with your CSAM and DataServ implementation team.

Troubleshooting and Support

Common situations:

• You are not sure whether you are on the new Organization Structure

  • Contact your CSAM or DataServ Support at support@dataserv.com.

  • Mention that you would like to confirm whether your account is on the new Organization Structure feature.

• Users can’t see documents they expect to see

  • Verify the user’s Organization Structure assignments (Region/Entity/Operating Unit/Location) in their account.

  • Confirm that the relevant structure elements are active and that the user is not limited to a different branch of the hierarchy.

• You need to add or change parts of your structure

  • Determine whether this is a minor update (e.g., adding a new location) or a larger re‑organization.

  • For any non-trivial change, contact your CSAM so it can be managed as a small project and coordinated with DataServ.

• You are planning or troubleshooting a multi-ERP setup

  • Work with your CSAM and DataServ implementation team.

  • Be prepared to share:

    • Which ERPs are in scope.

    • Which Regions/Entities/Operating Units/Locations belong to each ERP.

    • Any recent or upcoming changes in your ERP landscape.

For any questions or issues, contact DataServ Support at support@dataserv.com with:

• A description of what you are trying to do.

• Screenshots of any related Organization Structure configuration.

• Example users and documents impacted (including timestamps or IDs, if available).

Next Steps – Work with DataServ to Design and Configure your Organization Structure

Designing and configuring Organization Structure is a joint project between your team and DataServ. You bring the business model; DataServ handles the technical setup.

What Your Team Does

Work with your CSAM and DataServ to:

1. Initiate the project

   • Contact your Client Success Account Manager or email DataServ Support at support@dataserv.com.

   • Indicate that you want to set up or update your Organization Structure and mention if this includes multiple ERPs or API integrations.

2. Agree on your hierarchy

   • Confirm your top-level Regions (e.g., “US Retail”, “US Wholesale”, “EMEA”).

   • Define Entities within each Region (typically legal entities, company codes, or business units).

   • Define Operating Units within each Entity (aligned to your ERP concept such as Oracle Operating Unit or SAP Division).

   • Define Locations at the level of detail you need (site, store, plant, warehouse, etc.).

3. Provide IDs and ERP mappings

   • For each Region, Entity, Operating Unit, and Location, provide:

     • Names and any internal/ERP IDs you already use.

     • Which ERP(s) each part of the structure belongs to (for multi‑ERP clients).

     • Any special considerations (e.g., legacy entities that should remain for history only).

What DataServ does

DataServ will:

• Review your proposed hierarchy, IDs, and ERP mappings.

• Configure or import your Organization Structure in DataServ.

• Validate data, routing, and ERP assignments.

• Coordinate with you to:

  • Review the configured structure.

  • Test typical user access and document flows.

  • Confirm that Regions, Entities, Operating Units, Locations, and ERP assignments behave as expected.

• Plan go‑live timing and agree how future changes (such as new locations or entities) will be requested and scheduled.

You do not need to perform any technical import or configuration work yourself. DataServ will guide you through the process and implement the configuration based on the design you agree together.