Node Markups

Overview

Each Node, Sub-Node, and User has its dedicated "Node Markups" section. This screen enables clients to activate / diactivate contracts (Accounts) at each level of the hierarchy (Node, Sub-Node, or User).

As mentioned earlier, the HSP system operates hierarchically, Hence, activation of contracts at a specific hierarchy level is crucial. This functionality empowers the activation of specific contracts for certain Sub-Nodes and Users, while leaving them inactive for others who are not in use within those particular Sub-Nodes and Users.

👍

NOTE:

  • Each contract - represents a agreement between a client and its supplier or service provider.
  • Each contract - represents a single set of API credentials.
  • Client can have multiple contracts with one Supplier.
  • More information about Contracts (Accounts) - Click here.

Configuration

Activation on Client-Node

Once reached out to our Support Team to create a connection / contract with a supplier, the support team proceeds to establish the contract within the HSP system.

However, once this is done, the contract is initially placed under your Client Node but remains deactivated for all other Nodes and Users.

In order to Activate it:

  1. Activate it for the Main-Node (Client-Node).
  2. Activate it to the relevant Sub-Nodes and Users.

👍

NOTE:

If a contract is deactivated at the Sub-Node level, the users within that specific Sub-Node will neither see it nor have the capability to activate it.

Example:

After creating new contract - "SunHotels Live Net", and then navigating to the "Client Node", under "Node Markups" section - we can see that the contract is Diactivated by default :

Activation on Sub-Node

Activating a contract for a Sub-Node grants the users within that Sub-Node visibility and the ability to activate the contract. Conversely, if the contract is deactivated for the Sub-Node, its users won't have access to or to activate it.

This functionality empowers the System Administrator to differentiate the contracts associated with specific Sub-Nodes or Users.

Consequently, it allows for system configuration where each user or agent can access and activate only the contracts that pertain to their relevance.

Example:

If a contract is deactivated at the Sub-Node level, the "User" won't have the ability to view or activate the contract at their own level.

In this case - "AbreuOnline" is diactivated from the Sub-Node, Consequently, the "User" can not see or activate this particular contract.

Activation on User

As previously mentioned, a User can only access and activate contracts that are activated at their Parent Node. This implies that contract activation must be properly executed at each level of the hierarchy.

If a contract isn't visible to the User, please verify the Parent Node to ensure its activation. If the Parent Node is also unable to see the contract, activation at their respective Parent Node is necessary, and so forth. (This solely depands on your companies Hierarchy creation).

Example:

In this scenario, if we intend to activate certain contracts for the "User", it's essential to ensure proper activation at all higher-level Parent Nodes.

Consequently, for the User to gain access and activation privileges for these contracts, they must also be activated at the Agency level (Sub-Node), the Sub-Node level, and the Client-Node level.

Example of Client Hierarchy

Example of Client Hierarchy