Working with the Client Account Manager

Admins complete most day-to-day tasks in the Admin Panel. However, the Clowder team must configure some features and changes. Requests for these changes go through the Client Account Manager.

A simple rule applies. If a change affects one piece of content or one event, admins can make it in the Admin Panel. If a change affects the whole app for every user, such as the menu, whether a feature is available, or how data flows in from an integrated system, it goes through the Client Account Manager.

This page lists what admins can do on their own, which areas require a request, and how to plan and submit the most common requests.

Understanding what admins can do and what requires a request

The following table shows what admins can do in the Admin Panel and what requires a request to the Client Account Manager.

Planning requests

Submit requests as early as possible, and at least 4 weeks before go-live for anything that needs development. The following explains what lead times to expect with different request types:

• Requests that ASI completes through configuration, such as turning on a module or a setting, are typically quick.
• Requests that need development, such as groups with custom logic or IQA changes, are scoped first and then scheduled. The time starts when ASI has all the required information, not when the request is first submitted.

Submitting a request

To submit a request, contact the Client Account Manager and include the following information:

• Client or app name.
• Event name and a link to the event or record, if the request relates to one.
• Module or feature.
• A description of the change and the outcome wanted.
• The go-live date.
• A contact person for questions and testing.

The Client Account Manager confirms when the request is complete. Admins can then check the result in the Admin Panel.

Enabling modules

App modules are added to the app as menu items. A module not already in the app menu requires a request. The following modules are available as menu items:

• News Feed
• Events
• Live Events
• Event Gamification
• Event Manager
• 1:1 Meetings
• QR Hub
• Networking
• Messages
• Forums
• Resources
• Member Directory
• Membership Card
• App Users
• Notifications
• RSS/Podcast
• Higher Logic
• Web view

Options inside a module follow the same process, for example, Booth Wallet in QR Hub, or 1:1 Meetings inside Live Events.

In addition to the standard request information, include the following:

• The module and any options.
• The event, if the module is linked to an event.
• The menu name and position.
• Who should see the menu item (role or groups).
• The dates to show or hide the menu item.

Each Live Events, Event Gamification, and Event Manager menu item is linked to one event, so every event needs its own menu item. One request can cover several events.

After a module is enabled, admins configure its settings for each event in the Admin Panel.

Making content visible only to specific attendees

To make content visible only to a group of attendees, the Clowder team creates a group of those attendees and links the event content to it. The Clowder team also sets up the menu items if needed.

One piece of content can be linked to several groups. This works for News Feed posts, forum categories, polls, events, and resource folders and files.

In addition to the standard request information, include the following:

• The list of attendees and how they are identified (iMIS ID or email address).

• The modules that attendees should see.

• The event dates.

• The source of the attendee list: iMIS (using an IQA or API) or a file.

Whether the setup is a one-time task or needs repeating for each event depends on how the group is defined:

• Rule-based group: A group based on a rule, such as an iMIS attribute or an IQA, can be reused across events.

• Attendee list for one event: An attendee list for a specific event is set up for each event.
  Changes to the list after setup depend on the source:

• iMIS or IQA: The group picks up changes when Clowder syncs with the source.

• File: A file is loaded once and does not update afterward. To change the group, send an updated list to the Client Account Manager.

Changing an IQA used for an integration

An Intelligent Query Architect (IQA) is a tool in iMIS that builds queries to extract data from the iMIS database without requiring SQL knowledge. For more information, see Intelligent Query Architect (IQA) in the iMIS documentation.

For iMIS clients, Clowder can use IQAs for the following features:

• User and profile sync
• Groups and membership
• Event and attendee data
• Member directories
• Check-in push back to iMIS

Each client's setup differs. The Client Account Manager can tell a client which IQAs the app uses.

Data from an unchanged IQA keeps refreshing on its sync schedule. Users are also checked again when they log in or open their profile. However, changes to the IQA itself are not reflected in Clowder automatically, because the Clowder mapping depends on the IQA path and fields.

Report any of the following changes to the Client Account Manager:

• Adding or removing fields
• Changing filters
• Renaming the IQA
• Moving the IQA
• Deleting the IQA

To have a change reflected in Clowder:

1. Make the change to the IQA in iMIS.
2. Contact the Client Account Manager and include the standard request information and the following:
   • The IQA name and full path.
   • What changed (before and after).
   • The date of the change.
   • The feature that the change is expected to affect.
3. The Clowder team implements the change.

   ⚠️

   WARNING

   Changing the IQA required for an integration may stop data sync and updates between iMIS and Clowder. The Admin Panel shows no error when a modified IQA causes data sync issues.