RapidIdentity Product Guide

RapidIdentity Connect Standards

Naming Conventions

Action Set

Use proper case with no punctuation. Always start with a capital letter to distinguish from Core Actions.

  • Globals

  • DBToAD

When naming system-to-system Action Sets, use the system names. If there is more than one system of the same type, describe it with the system type.

  • TextStaffToAD

  • ADIdautoToGoogle

  • DBStudentsToEdirAcme

For alternate actions, use the module and action name

  • ACTMChangePassword

  • SPMCreate

For workflow actions, preface the Action Set name with "WFM"

  • WFMProvisionAccount

  • WFMDeprovisionAccount

  • WFMManageGroupMembership

For special purpose Action Sets that act like a "function", use an "Fn" prefix

  • FnGeneratePassword

  • FnHasRecordChanged

Action Set Category

The following are the standard Action Set categories (folders)

  • “lib” - Contains helper Action Sets (e.g. Global, HasRecordChanged)

  • “Tools” - Support provided Action Sets (e.g. ArchiveLogs)

  • “Identity” - System to system related Action Sets that provide identity and access management functionality (e.g. TextStaffToAD)

  • “Reports” - Action sets that create reports and/or report data

  • “Manual” - Action sets that are run periodically or ad-hoc basis

For alternate actions, place by their module:

  • “ARMS|SPM”

  • “ARMS|GMM”

The “|” character creates subfolders.

Input Properties

Use lower case with underscores

  • key_field

  • key_value

  • log_only

Local Variables

Use lower case with underscores

  • current_time

  • default_password

Global Variables

Always start with “Global”

Use system prefix with camel case

  • Global.adHost

  • Global.ldapUser

  • Global.armsURL

General Standards
Using core and custom schema definitions properly

  • Do not store values in core schema that doesn’t describe the data. For example, don’t store a job code value in the physicalDeliveryOfficeName attribute.

  • Verify the use of custom attributes with a Solution Architect (or Manager of Services) to ensure proper use

  • Requests for new custom attributes must be made to Solution Architect (or Manager of Services)

Storing Employee and Student IDs

  • Use “employeeID” attribute for storing employee ID’s and student ID’s.

  • If there is a chance of overlap, add a prefix of “E” for employees or “S” for students. Store the *original* value in the “employeeNumber” attribute. For example, an employee with an employee ID of 1234 would have employeeID=E1234 and employeeNumber=1234.

Use of quotations

  • Always use double quotes (“) when referring to strings

  • The only exception is when you have a string within a string, in which case you will use a single quote for the inner string (‘). e.g. “INSERT INTO table (‘column1’) VALUES (foo’)”

Referring to record field values

  • Always refer to record fields using record[‘field’] syntax. (i.e. refrain from using record.field)

  • Using consistent syntax helps everyone understand the usage.

    • record[‘givenName’].toUpperCase() <-- standard

    • record.givenName.toUpperCase() <-- not standard

Common Schema Usage

AD Attribute

Description

givenName

First name

sn

Last name

middleName

Middle name

employeeID

Employee or student ID

idautoPersonJobCode

Job code

title

Job title

departmentNumber

Department code

department

Department name

idautoPersonPriLocCode

Location/building/office/campus code

physicalDeliveryOfficeName

Location/building/office/campus name

streetAddress

Address

l

City

st

State

postalCode

Zip code

mail

Email address

displayName

Full name

employeeType

Person type (e.g. Staff, Student, Sponsored)

idautoStatus

Account status (e.g. A, I)

idautoPersonGradeLevel

Student grade level

In this section: