Custom Plugin Overview

Understand all about custom plugin.

Custom plugins are mini web applications that add specific functionalities to the Staffbase platform. To your users, these custom plugins function very much like the standard plugins offered by Staffbase. Learn more about plugins.

To provide real value with a custom plugin, learn more about custom plugins and how different target groups use them – from those who install and manage them, to those who finally use the custom plugins in your app or intranet. In addition, understand how custom plugins work behind the scenes.

Custom plugins work in the same seamless manner as the standard plugins offered by Staffbase work.

Learn more about how standard plugins work for administrators to users here.

To understand how a custom plugin works, let’s take a look at what is happening behind the scenes:

Custom plugins are web applications that are developed by our partners or customers. These web applications are hosted outside the Staffbase platform and embedded into the platform using iframe elements.

Once the custom plugin is deployed to the Staffbase platform, the custom plugin is available to your organization. Administrators can install the plugin, add multiple instances of the same plugin, make them available to relevant users, and, finally, manage edits and updates to the different instances of the plugin.

There are 5 steps involved in making the content of a custom plugin available to users:

Once a user tries to access the custom plugin, all the following steps happen behind the scenes automatically in a matter of seconds.

  1. Requesting access: The user accesses the custom plugin content on the Staffbase client. This attempt to access the content is considered as a request.
  2. Forwarding the request: Staffbase client forwards the user request to the identity provider, in this case, the Staffbase server.
  3. Redirecting the request: The identity provider appends the request with access parameters in the form of . The appended request is redirected to the pre-defined endpoints of the host, where the custom plugin is hosted.
  4. Authenticating the request: The host authenticates the constraints pre-defined in the JWT and returns the response to the Staffbase client.
  5. Granting access: Once the Staffbase client receives the successful authorization response, the plugin content is displayed to the user.

In this process, access to the content is only granted after successful JWT authentication. This ensures that the data exchange is secure.

The mode of access determines whether the custom plugin content is available to users who are logged in or the general public. You can choose the mode of access in the design phase, when defining the scope of the custom plugin.

The different modes of access are:

This is the most commonly used mode of access. In this case, the custom plugin is available only once users log in to their employee app or intranet. This mode of access ensures that the data is safe as only authorized users have access to the content.

Example of JWT request in normal mode:

{
    "aud": "mycustomplugin"
    "exp": 1614507233
    "nbf": 1614507143
    "iat": 1614507173
    "iss": "staffbase-backend-liveDE"
    "branch_id": "5e2bfa932f456c5e1dd5141f"
    "branch_slug": "mycompany"
    "instance_id": "5e321ef813e518a44a8264b8"
    "instance_name": "My Custom Plugin"
    "sub": "5e3bfa989f466c5f1cc51442"
    "external_id": "1337"
    "username": "john.doe"
    "primary_email_address": "john.doe@company.com"
    "tags": [
        "profile:location:chemnitz",
        "profile:department:support-engineer"
    ]
    "name": "John Doe"
    "given_name": "John"
    "family_name": "Doe"
    "role": "editor"
    "type": "user"
    "theming_text": "#FFFFFF"
    "theming_bg": "#FBC91E"
    "locale": "en_US"
}
  • The role parameter is the role of the accessing user. If this is set to “editor”, the requesting user may manage the contents of the plugin instance (instance_id), i.e. she has administration rights.
  • The type parameter is the type of the accessing entity. This could be either a “user” or a “token”.
  • The primary_email_address, username and tags parameters are not sent by default.

Please contact support@staffbase.com to activate the primary email address and/or username for your custom plugin. The tags parameter contains all profile fields enabled for group tagging that are filled for the accessing user.

This mode does not require user credentials to process the authentication request. Anonymous mode is not often used, as organizations have only a few business use cases, where a plugin needs to be made available in the public area before users log in.

Example of JWT request in anonymous mode:

{
    "aud": "map"
    "exp": 1614507233
    "nbf": 1614507143
    "iat": 1614507173
    "iss": "staffbase-backend-liveDE"
    "name": "Staffbase system: Public area"
    "instance_id": "5ec15fb01d145226c5631a84c"
    "instance_name": "Maps"
    "type": "token"
    "theming_text": "#FFFFFF"
    "theming_bg": "#FBC91E"
    "locale": "en_US"
}