About App Modules

App Modules give suppliers the opportunity to create their own custom integrations to their partner portal, connecting other applications and extracting their data if required, and exposing them in the portal for partners to use. They can be employed in addition to a partner’s own integrations to CRMs such as Salesforce or Zoho, which allow the exchange of lead and contact data.

Here’s a couple of sample use cases:

• You may have MDF funds managed in a 3rd party application such as WorkSpan. Adding connections to WorkSpan’s APIs allows your partners to access information about both their Unifyr marketing activities and their MDF fund activity from the portal.
• You want to inject a digital adoption application such as WalkMe or Chameleon into your portal, so that you can give users guidance on how to use the site.

There is no limit to the number of App Modules you can manage in Unifyr Admin. They can be activated or deactivated at any time.

An App Module typically consists of these configuration items:

• Service Authentication objects - hold the credentials and security information for each connected application. These are optional.

  These authentication methods are supported:

  • Basic HTTP Authorization
  • Bearer
  • OAuth2
  • Authorization Token

  Authentication requirements are defined by the target application itself.

  It’s also possible to use No Authentication - authentication may not be required to access data, for example if connecting to a data source in Unifyr (the portal user is already logged in)

• Data Connector objects - define where to get data from, and the API calls that will access the data

  A Data Connector object references a Service Authentication object, either No Authentication or the object that represents the login/security details for the target application.

  They support GET, POST, PUT, and PATCH calls to the specified API.

  Data Connectors can be daisychained together, with each object using the information extracted by the previous one. For example to get a user’s MDF Fund activity from WorkSpan you might first need a call to their User API to get the portal user’s WorkSpan username, then include the username in a call to the MDF Fund Membership API to confirm the fund to which the user has access, then finally a call to the MDF Funds Activity API using the fund name.

• Component objects - specify how data or code will be used / delivered in the portal

  A Component object can reference a Data Connector object that extracts the data from the target application. They can also be employed on their own.

  Three types of Component are supported:

  • Page Runner - made available in a specific portal page

    When creating a Page Runner type component, you can provide an Angular template that specifies how the received data will be formatted. Data can be from multiple connections.

    You can use a Dynamic Content widget to include this type of component in a custom page in your portal.

  • Site Modifier - adds functionality to the partner portal

    When creating a Site Modifier type component, you can provide JS code to be injected into the header and/or footer of the portal site, which runs when the portal loads.

    You can also include code that runs every time a user changes page in the portal.

  • Form Submission - provides a form for portal users to complete

    When creating a Form Submission type component, you can provide an Angular template that specifies how the forms looks in the portal. You also define the location to which to post the data when the form is submitted.

    You can use a Dynamic Content widget to include this type of component in a custom page in your portal.