Account Management

This solution describes how you can create, modify, and remove accounts in the Attendance on Demand system. It can help you determine which use case best meets your business needs and guide you through the implementation.

  1. Background
  2. Use Cases

Background

Attendance on Demand allows Individual Access Accounts to be maintained via the web services API for ease of use in an SSO context. This way the user does not need to remember the account name and password on the Attendance on Demand system. Instead, the system performing the SSO can manage the AoD account.

Typical web service integrations only require one Attendance on Demand Access Account per database. This account is only used for your application to retrieve and update employee data, workgroups, and benefit balances. This Access Account should be granted an Administrative level Browser Profile and User Group and should be given access rights to all employees.

Function

Add, update, or retrieve Access Accounts in an Attendance on Demand system.

Account Information Types

Basic Information

  • Structure - TAeAccessAccount
  • Basic employee accounts consisting of
    • Account Code
    • Account Type
    • Browser Profile
    • eMail Address
    • Username
    • Password
    • Assigned Workgroups

Use Cases

Attendance on Demand has identified use case scenarios for managing account information.

Consult the table below to find the use case that aligns with your business needs, click the entry for a detailed explanation.

Use Case 1 - Creating a New Account

Create a new account to the database using the TAeAccessAccount Structure

Highly recommended/best practice to use the addAccessAccount method

Preconditions

If a single sign on is to be implemented for MSS, an Attendance on Demand access account needs to exist with the appropriate Browser Profile, User Group and employee access rights for each user using single sign on. This is also true when making changes to a timecard via web services on behalf of a user. When a timecard is modified, the account used to make the modification is recorded for legal reasons. A generic account cannot be used for timecard modifications.

API Usage

To create an account via the API, addAccessAccount is used. A code example for creating a new account is show below.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
TAeAccessAccount acct = new TAeAccessAccount();
acct.AccountCode = "TestUser";
acct.AccountType = 0;
acct.BrowserProfile = service.getBrowserProfilesSimple()[0];
acct.eMailAddress = "test@sample.com";
acct.FriendlyName = "Test User";
acct.Password = "newpassword";
acct = service.addAccessAccount(acct);
 
acct = service.getAccessAccountViaAccountCode(acct.AccountCode);
 
TAeWorkgroupSet wgAssmt = new TAeWorkgroupSet();
wgAssmt.WG1 = 1;
wgAssmt.WG2 = 3;
wgAssmt.WG3 = 1;
service.addAccessAccountWorkgroupAccessRightByAccountCode(acct.AccountCode, wgAssmt);

An instance of the TAeAccessAccount is created and populated with appropriate values. This is the point where the browser profile is assigned to the user. In this example a list of available browser profiles are retrieved and the first one is selected. addAccessAccount is the API method that adds the account. Its return value is the TAeAccessAccount structure with updated values as a result of the add action.

In the next portion of the code the workgroup permission is added to the account using addAccessAccountWorkgroupAccessRightByAccountCode. This would be done for each workgroup the user has access to.

Employees do not need Access Accounts to perform employee functions such as functionality found in ESS

Use Case 2 - Modifying Access Accounts

Access Accounts can be modified via the web services API using editAccessAccount

Preconditions

  • Account must exist

API Usage

Use Case 3 - Removing an Account

Method removes an account

Preconditions

  • Account must exist

API Usage

Back to Top