• Success
    Manage your Success Plans and Engagements, gain key insights into your implementation journey, and collaborate with your CSMs
    Accelerate your Purchase to Value engaging with Informatica Architects for Customer Success
  • Communities
    A collaborative platform to connect and grow with like-minded Informaticans across the globe
    Connect and collaborate with Informatica experts and champions
    Have a question? Start a Discussion and get immediate answers you are looking for
    Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
  • Knowledge Center
    Troubleshooting documents, product guides, how to videos, best practices, and more
    Knowledge Center
    One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
    Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
    Information library of the latest product documents
    Best practices and use cases from the Implementation team
  • Learn
    Rich resources to help you leverage full capabilities of our products
    Role-based training programs for the best ROI
    Get certified on Informatica products. Free, Foundation, or Professional
    Free and unlimited modules based on your expertise level and journey
    Self-guided, intuitive experience platform for outcome-focused product capabilities and use cases
  • Resources
    Library of content to help you leverage the best of Informatica products
    Most popular webinars on product architecture, best practices, and more
    Product Availability Matrix statements of Informatica products
    Monthly support newsletter
    Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
    End of Life statements of Informatica products
Last Updated Date May 25, 2021 |


Setting up Partners, Accounts, User Groups and Roles in DX requires careful consideration; it is essential to determine the definition of these objects and how they will be used before the implementation phase begins.


A partner represents an external or internal entity that sends documents to be processed or receives documents processed in B2B Data Exchange. A partner can be an organization, such as a vendor, customer or an internal system (e.g., an accounting application or an ERP system).


Accounts are sub-entities of partners. In a customer organization, an account can be a unit, such as a division, department or subsidiary. For an internal system, an account can be a unit, such as a customer ID or vendor code.


Often, DX handles a data integration solution which encompasses the exchange of information with both external and internal entities. Setting up the definition of partners inside of DX should be completed in advance in order to avoid costly changes in the future. Examples of partners include:


  • Different banks with which an organization exchanges electronic payment information.
  • Different hospitals with which an organization exchanges patient health records.
  • Various vendors from which an organization receives customer invoices in various different formats.

Categorize Partners Early

Partners can be identified as: an external entity/organization with whom information or documents are exchanged or an entity internal to the organization. Another classification can be based on Partners required for internal document processing. Categorize partners early in the discovery process in order to identify opportunities for reuse and to prevent duplication of information.


Create multiple partners representing the various banks to which an organization might send payments, but it is not recommended to create multiple partners representing a file processing endpoint.


Partners should at least be split into Internal and External; further classifications can be created as needed(e.g., a category called Internal Processing can be made to classify all partners created to handle internal processing by DX, such as those needed by Endpoints).


Also, it is recommended to control the access to partners belonging to different categories (i.e., have specific user groups assigned to each partner category). For example, consider splitting the operators in an organization by geographical region; if partners are categorized into East and West, then create two categories: East and West. Additionally, create an East and West user group which will be assigned privileges only on the respective category. In other words, the west operator group will only Read/Write privileges to West region partners; if necessary, they may be granted read access to East region partners.


Architecting B2B Data Exchange Entity 1
Architecting B2B Data Exchange Entity 2
Architecting B2B Data Exchange Entity 3

Identify Users Groups

In advance, identify the different users who will be accessing DX and the typical workflow that they will follow to perform their daily activities. This can be useful in defining the necessary privilege levels.


By default, DX is equipped with the following roles, and it is recommended to use these to classify the users. For example, a business user will not need the same level of privileges as a system administrator or an operator.


  • System administrator (Sysadmin)
  • Administrator or admin
  • Operator
  • Developer
  • Analyst


Each role has its own default privileges which can be controlled through the DX console.


Architecting B2B Data Exchange Entity 4

The privileges assigned to a specific user can be further refined by using the checkboxes above. The following actions should be limited in order to prevent unnecessary disruptions:


  • Reprocess events
  • Resend events
  • Run monitors
  • Change event status
  • Run profile


Reprocessing events and resending events are of special importance; if these are used without proper care, then it might result in unnecessary use of system resources and erroneous results.

Access Control using Event Type

In B2B DX, each processed document creates an event but these might not be relevant to all users. For instance, consider a payment processing system which monitors payments sent to banks and their status in the form of acknowledgements, negative acknowledgements and statements received from the bank. Mainly, a business user will be interested in seeing the following:


  • Status of payments sent
  • Whether they were acknowledged
  • Whether they failed acknowledgement
  • Whether statements were received for them


In DX, an event will be created for the arrival of an acknowledgement of a payment, a statement and several other events (e.g., system events). The business user needs to be shielded from these event types to prevent them from being overwhelmed. The following DX screen assigns the privileges to a business user so that they only view specific types of events.


Architecting B2B Data Exchange Entity 5

Table of Contents


Link Copied to Clipboard