Space / Space Inventory (Transactional Method)
Space / Occupancy (Transactional Method)

Examples: Workspace Transaction Records for Individual Moves

This topic walks through the exact steps that occur when an employee moves under different scenarios. Review this topic if you require an exact understanding of how the system uses workspace transactions for an employee move.

Scenario 1: Smith requests to move from room 101 to 102

On Feb 10, employee Smith requested to move from room 101 to room 102. The request was approved. Note the following configuration:

  • The InferRoomDepartments application parameter is set to Yes, meaning that the Workspace Transaction record's division and department values are updated to the division and department of the employee occupying the room.
  • The AssignUnallocatedSpace application parameter is set to assign vacated space back to the room's primary division and department
  • Smith is assigned to the DEV-CORE department.
  • His original room, 101, is assigned to the MKTG-COMM department. While he occupied this room, the Workspace Transaction reflected his departmental assignment.
  • The room to which Smith is moving, 102, has a capacity of 2 and is currently empty.

The tables have the following values:

emp_move1.GIF

Note the following:

  • For room 101. the Workspace Transaction record for Smith (PCT ID 1) now has an end date of Feb 9, and a new Workspace Transaction record PCT_ID 4) has been created beginning on Feb 10 to assign this room back to MKTG-COMM.
  • Room 102 has a capacity of 2, so when Smith moves to this room the system creates a Workspace Transaction record (PCT_ID 5) to reflect that beginning on Feb 10, Smith occupies 50% of the room and this share of the room is assigned to Smith's department, DEV-CORE. The Workspace Transaction for this 50% of space now has an end date of Feb 9. Notice how Smith's department assignment, DEV-CORE, is now assigned to the 50% of space that Smith occupies in room 102.
  • The record with PCT_ID of 2 documents that 50% of room 102 does not yet have an employee.

Scenario 2: Room 102 is already occupied by Jones when Smith moves in

Let's change the scenario and suppose that Jones is assigned to the MKTG-COMM department and occupies 50% of room 102. The other 50% of room 102 is empty; this is represented by record PCT_ID 3 in the initial Workspace Transactions table.

Since there was already an empty workspace transaction record for room 102 (PCT_ID 3), Smith’s move does not affect Jones. The system sets the End Date of the empty seat (PCT_ID 3) to February 9 to show that the room is no longer empty.

emp_move2.GIF

Scenario 3: Room 102 has a capacity of 1, and Smith’s move makes room 102 over-capacity

Suppose that Smith wants to move to room 102, which has a capacity of 1. Jones already occupies 100% of this room and is assigned to the MKTG-COMM department.

The records for room 101 remain the same as above.

The system updates the existing record for Jones (at 100% of the room) with an end date of Feb 9. The system creates a new record (PCT_ID 5) for Jones, giving him 50% of the room; the system creates another new record for Smith (PCT_ID 3), giving him the remaining 50% of the room. Each seat in the room is attributed to the appropriate department.

emp_move3.GIF

Note:

  • The system created workspace transaction records to ensure 100% allocation.
  • If Jones moves out of 102, the system will not create a Workspace Transaction record to show this vacancy. The system tries to reduce the number of transaction records for each room to meet capacity.

Scenario 4: Jones requests to move out of Room 102 on Feb 8, before Smith moves in. Room 102 has capacity of 1.

On February 8, Smith requested to move from room 101 to room 102 (with a capacity of 1). Suppose Jones occupies 100% of room 102 and has already requested to move out of room 102.

emp_move4.GIF

In this case, the system:

  • gathers the future requests
    emp_move_gather.GIF
  • removes those requests and associated transactions by calling the deleteEmployeeAssignment workflow rule
    emp_move_remove.GIF
  • re-orders the requests chronologically, and re-insert the transactions by calling the insertUpdateRmpctRecordsFromMoveServiceRequest workflow rule.
    First, it re-orders Jones on February 8.
    emp_move_reorder1.GIF
  • Then, it re-orders Smith on February 10.
    emp_move_reorder2.GIF

Note:

  • Room 102 was vacant for just two days – the 8th and the 9th – before Smith moved in
  • Smith gets 100% of room 102 because nobody had occupied room 102 at the same time; thus, the room was never split.

Scenario 5: Jones requests to move out of Room 102 on the same day as Smith moves into Room 102

Initially, the Workspace Transactions table appears as below, with both requests with a status of Requested.

emp_move5.GIF

The Workspace Transaction table appears as below when all requests are approved.

emp_move5b.GIF