Mapping Users

Mapping resources is an administrative task that will typically be performed before users start using a client application.

Mapping resources can then be performed on an ongoing basis as resources are added or removed from the system, or if the organization model is revised (for example, new positions or groups).

Mapping resources involves assigning resources to specific groups and/or positions in an organization model, which results in the resources receiving work items that are sent to the groups/positions to which the resources have been mapped. Resources can be mapped to:

  • A group, which represents a job type within the organization. It allows resources to be grouped by their job characteristics.

    Groups can be hierarchical, i.e., you can have parent groups with sub groups. For example, you can have a CustomerServiceRepresentative group with subgroups of MotorInsuranceSpecialist, TravelInsuranceSpecialist, and HomeInsuranceSpecialist. Typically, sub-groups are specializations of the parent group. Groups can be nested several layers deep.

    If a group has sub-groups, you can assign resources to either the parent group or the sub-group. Resources that belong to sub-groups receive work items that are offered to their parent groups, as well as to the sub-group to which they belong. Using the example above, resources in the MotorInsuranceSpecialist group will also receive work items offered to the CustomerServiceRepresentative group.

  • A position, which represents a set of responsibilities for a job within an organization unit. It allows resources to be grouped by job responsibility.

    Positions are subordinate to an organization unit in the organization model. An organization unit can have many positions. For example, you can have a TravelInsurance organization unit with positions of OfficeManagerTravel and TravelInsuranceCSR. Positions cannot be nested, although organization units can.

    Resources can be mapped to positions, but not organization units.

    Resources that belong to a position receive work items offered to the position, as well as work items offered to the organization unit that is the immediate parent of the position.

Before a resource can be mapped to group or position, the resource must be created. This is accomplished with the createResource function. Creating the resource assigns a GUID to that resource.

After being created, a resource can log into an ActiveMatrix BPM application, even if the resource has not been mapped to a group or position yet; the resource would not have access to any work items, however, as work items are only sent to resources mapped to groups or positions.

Also note that you will see references to whether or not a resource exists; a resource exists if it has been created with the createResource function.

The following diagram shows an example of how calls to functions in OrgModelService, DirectoryService, and OrgResourceService can be used to map users.

Mapping a User

Procedure

  1. Call getOrgModel to get details about the entities in an organization model identified by its major version number (you can obtain the major version numbers using listOrgModelVersions).

    The response from the getOrgModel function provides the GUIDs for all entities in the organization model, including the positions and groups to which users can be mapped.

  2. Call listContainers to list the LDAP containers to which you (the calling user) have access. LDAP containers contain resources that can be mapped to groups and positions in the organization model.

    The response from the listContainers function provides names, descriptions, and other information about each container, as well as the container ID (id attribute).

  3. List the available resources (candidates) in the specified LDAP container.

    The listCandidateResources function can be used to list:

    • all resources in the container by passing "ALL" in the includes parameter,
    • the existing resources (that is, those that have been created already with the createResource function) by passing "EXISTING" in the includes parameter, or
    • the resources that do not exist yet (that is, the resources in the container that have not been created yet with the createResource function) by passing "NON-EXISTING" in the includes parameter.

      The response from the listCandidateResources function provides an ldap-dn for all available resources; for resources in the container that already exist, the resource’s GUID is also returned.

  4. Create the resource(s) that you want to map; you can skip this step if you are mapping only resources that already exist (that is, they have already been created and have a GUID assigned to them).

    Call createResource, identifying the LDAP container in which the resource resides, as well as the ldap-dn, which identifies the resource. If a secondary LDAP source is defined for the container, you must also identify that source in the request.

    The response from the createResource function returns the GUID that is assigned to the resource when it is created. The response also contains an already-present attribute that tells you whether or not the resource was already created.

  5. Map the resource(s) to the desired groups or positions using the updateResource function.

    The updateResource function request identifies the resource, as well as the groups and positions to which you are mapping the resource; they are all identified with GUIDs. (Note that the updateResource function can be used to also assign privileges, capabilities, locations, resource attribute values, and so on.)

    The response from the updateResource function acknowledges the update by returning properties for the updated resource.