Automation repository

Scenario description

• Automatically sends a message to cancel in case no occupancy has been detected during the first X minutes after the start of the reservation. 

  • It’s also possible to define a buffer period (Z minutes) prior to reservation start: if presence is detected during this grace period, the Automation will not be executed

• Sends a message to the meeting organizer containing a deep-link. When clicked, the meeting will not be cancelled, independently on the detection of presence.
• The system will auto-cancel the meeting Y minutes after the message has been send (and in case no occupancy has been detected in the meanwhile).

Info

Best practice is to only define Buffer time/Grace period for Workplaces, as you’d want to optimize the use of meeting rooms.

Scenario exceptions

• If no phone number/e-mail address is available, the scenario will not be executed.
• If no presence signal (of any kind) has been received for 24 hours, the scenario will not be executed.
• Multi-day booking feature is not compatible with this Automation . Therefore multi-day reservations are filtered out and not taken into account for this Automation.

Components

• Buffer Time (grace period) before message is triggered Z

  • Default = 0 minutes (defined in milliseconds)

• Time before message is triggered X

  • Default = 15 minutes (*)

• Time after the message has been send and canceling the reservation Y

  • Default = 10 minutes

• Message type

  • Options = Mail or SMS

  • Default = e-mail
• Message subject for e-mail

  • Default = “Your reservation is about to be cancelled"

• Message text

  • Default = “We noticed your booked space (<NAME>) is empty. We’ll cancel it in 10 minutes. If you’re running late, click this link and we’ll keep it alive: <deep link>”

• Locations

  • Options = All locations (where presence is measured) or a selection of locations (for example only meeting rooms)

Requirements

• Sensors linked to the location(s) are required to provide a heartbeat at least every 24h
• Dedicated User needed: To change reservation details, a dedicated employee (that can be used as Reservation Responsible) and account (which should be used by the Automation exclusively) are needed. Ideally, set up a system account which can perform the required operations.
• In case of SMS message: A Clicksend account (https://www.clicksend.com/eu/ ) with sufficient budget needs to be made available by the customer.
• The phone number and/or the e-mail address of the reservation responsible needs to be configured
• Location Scope (choose a specific location set (= static list) or apply the scenario to all the locations of the same category in the same building or on the same floor (dynamic)):

  • static: provide a list of all the locations (based on Spacewell location ID) to which this scenario should apply by using following template.

Additional comments

(*) When occupancy is measured using Browan PIR sensors, the "time before the message is triggered" cannot be lower than 15 minutes. Since Browan PIR sensors only send a new "occupied" signal anywhere between every 8 - 12 minutes, every value lower than 15 minutes would trigger faulty messages to be distributed. When measuring occupancy using Pointgrab sensors, the "time before the message is triggered" can be as low as 1 minute.

Spacewell Workplace Team will require the ID of each location to link the Automation (and Floor ID if locations are on different floors). This allows you to detail if there is a difference in "reaction time" ("after X minutes") for eg meeting rooms and workplaces.

Spacewell Meeting Room Displays (MRD) have a stand-alone grace period functionality. If this is used in combination with the described Automation, it will cause a conflict. If the user clicks on “confirm” in the email or SMS, they still need to “confirm” on the display too. If this is unwanted behavior, the grace period for the display can be disabled.

Possible customizations of this scenario while staying within setting up a standard scenario (per tenant per Automation)

• Time before message is triggered X (see additional comments for minimal time per sensor type)
• Time after the message has been send Y
• Message type: e-mail or SMS
• Message subject for e-mail: you can deliver an alternative text, as long as the standard tags are respected
• Message text: you can deliver an alternative text, as long as the standard tags are respected (<NAME> and <deep link>)
• Time between sending a message and canceling the reservation
• Location scope
• Additional confirmation by clicking a button instead of just confirming by clicking the deep-link (see description in above chapter "How does it work")

Additional comments

(*) When used in combination with the auto-cancel scenario, you want the auto-end scenario only to kick-in after a while. For example: when in the first 15 minutes no presence was detected, you want the meeting to be cancelled. If no presence is detected afterwards, you want the meeting to be made shorter automatically.

(**) When occupancy is measured using Browan PIR sensors, the "time before the message is triggered" cannot be lower than 15 minutes. Since Browan PIR sensors only send a new "occupied" signal anywhere between every 8 - 12 minutes, every value lower than 15 minutes would trigger faulty messages to be distributed. When measuring occupancy using Pointgrab sensors, the "time before the message is triggered" can be as low as 1 minute.

The Workplace Team requires the ID of each room to link the Automation (and Floor ID if rooms are on different floors). This allows you to detail if there is a difference in "reaction time" ("after X minutes") for eg meeting rooms and workplaces.

Possible customizations of this scenario while staying within setting up a standard scenario (per tenant per Automation)

• Time X before message is triggered: The timer starts counting as soon as no-occupancy is detected (see additional comments for minimal time per sensor type)
• Message type: e-mail or SMS
• Message subject for e-mail: you can deliver an alternative text, as long as the standard tags are respected
• Message text: you can deliver an alternative text, as long as the standard tags are respected (<NAME> and <deep link>)
• Time between sending a message and ending the reservation
• Location scope
• Additional confirmation by clicking a button instead of just confirming by clicking the deep-link (see description in above chapter "How does it work")

Additional comments

When occupancy is measured using Browan PIR sensors, the "time before the message is triggered" could be 15 minutes. Since Browan PIR sensors only send a new "occupied" signal anywhere between every 8 - 12 minutes, every value lower than 15 minutes would trigger faulty messages to be distributed. When measuring occupancy using headcount sensors, the "time before the message is triggered" will be 1 minute.

The Workplace Team requires the ID of each location to link the Automation (and Floor ID if locations are on different floors). This allows you to detail if there is a difference in "notifications to be triggered for the same event in time" ("message is sent every X minutes per location") for eg meeting rooms and workplaces.

Possible customization of this scenario while staying within setting up a standard scenario (per tenant per Automation)

• Duration “X” for repeated messages
• Message type: e-mail or SMS
• Message subject for e-mail: you can deliver an alternative text, as long as the standard tags are respected (${location.name})
• Message text: you can deliver an alternative text, as long as the standard tags are respected (${room/workplace name} and ${building name})
• Location scope

Possible customization of this scenario while staying within setting up a standard scenario (per tenant per Automation)

• Duration “X” for repeated messages
• Message type: e-mail or SMS
• Message subject for e-mail: you can deliver an alternative text, as long as the standard tags are respected (<room/workplace name>)
• Message text: you can deliver an alternative text, as long as the standard tags are respected (<headcount for room or workplace>, <room/workplace name>, <building name> and <upper limit utilization threshold for room or 1 in case of workplace >)
• Location scope

Possible customization of this scenario while staying within setting up a standard scenario (per tenant per Automation)

• Duration “X” for repeated messages
• Message type: e-mail or SMS
• Message subject for e-mail: you can deliver an alternative text, as long as the standard tags are respected (<room/workplace name>)
• Message text: you can deliver an alternative text, as long as the standard tags are respected (<headcount for room or workplace>, <room/workplace name>, <building name> and <upper limit utilization threshold for room or 1 in case of workplace >)
• Location scope

Possible Automation scenarios for locations where door counter sensors are installed:

Possible Automation scenarios for Status lights (LoRa) :

Additional Comments

There is only 1 scenario per light possible.

Get in touch with your Spacewell Account Manager to request an Automation and describe which of the 3 scenarios should apply. The colors are derived from floor plan settings as mentioned above.

Possible customization of this scenario: NA

Additional Comments

There is only 1 scenario per light possible.

Get in touch with your Spacewell Account Manager to request an Automation and describe which of the 3 scenarios should apply. The colors are derived from floor plan settings as mentioned above.

Possible customization of this scenario: NA

Additional Comments

There is only 1 scenario per light possible.

Get in touch with your Spacewell Account Manager to request an Automation and describe which of the 3 scenarios should apply. The colors are derived from floor plan settings as mentioned above.

Possible customization of this scenario: NA

Possible Automation when no devices are installed:

Additional comments

Spacewell Meeting Room Displays (MRD) have a stand-alone grace period functionality. If this is used in combination with the described Automation, it will cause a conflict. If the user clicks on “confirm” in the email or SMS, they still need to “confirm” on the display too. If this is unwanted behavior, the grace period for the display can be disabled.

Possible customization of this scenario while staying within setting up a standard scenario (per tenant per Automation)

• Timing confirmation period (max 24h prior to reservation start)
• Timing grace period
• Message type: e-mail or SMS
• Message subject for e-mail: you can deliver an alternative text, as long as the standard tags are respected
• Message text: you can deliver an alternative text, as long as the standard tags are respected (<ROOM NAME>, <CONFIRMATION PERIOD>, <DEEP LINK>, <GRACE PERIOD> and <DEEP LINK>)
• Location scope
• Additional confirmation by clicking a button instead of just confirming by clicking the deep-link (see description in above chapter "How does it work")

Custom Automation

If you are a creative person and want to create Automation scenarios which are in the same trend as the scenarios above, but which are not exactly the same; we also have a solution for you: use the template below and send send in a product request via your Spacewell Account Manager. Budget and implementation timing will vary based on your request.

Scenario description

• Describe your scenario in words.
• Make sure you think about all cases that occur.
• Only describe rules & triggers for events that are currently already captured in Workplace (if we don't have the info in the system, we can't make an Automation).

Scenario exceptions

• When will the Automation not work?

Components

• Define the scenario variables and their contents

Requirements

• What is needed from the system (configuration) to make this happen?

Quality Assurance

After implementing 1 or more Automation scenarios for your environment, make sure to test if everything is working as it should. Visit page Quality Assurance Occupancy and Utilization Sensor for tips & tricks on how to test this.

Automation scenarios take action based on the sensor values from the sensor that is linked to the same location, so to do Quality Assurance on the sensor installation, please see above.

To do Quality Assurance on the different https://spacewell.atlassian.net/wiki/pages/resumedraft.action?draftId=492317 configured for the tenant, create some test scenarios:

• Auto release Reservation when no occupancy is detected (and send a message) :

  1. Select a location for which the above Automation scenario is configured

  2. Make sure that

     1. the motion sensor for that location cannot be triggered in the upcoming time (best practice is to close the door in case of a closed meeting room, and keep an eye on the door to make sure a colleague does not go in/triggers the sensor)

     2. if there is a Meeting Room Display configured to this location, make sure the Auto-Release functionality has been disabled
  3. Make a reservation at this time for the selected location on any of the Workplace touch points, with a user that is configured with as per the Automation requirements (for example phone number and/or e-mail address of the reservation responsible needs to be configured)
  4. If the Automation is working, you should get a message + the location will be cancelled (reservation object receives flag "cancelled")
• Auto-end Reservation when no occupancy is detected (and send a message) :

  1. Select a location for which the above Automation scenario is configured

  2. Make a reservation for the selected location on any of the Workplace touch points, with a user that is configured with as per the Automation requirements (for example phone number and/or e-mail address of the reservation responsible needs to be configured)
  3. Enter the location at the meeting start time and make sure the motion sensor is triggered. After some time, go away from the location. Make sure the sensor cannot be triggered (best practice is to close the door in case of a closed meeting room, and keep an eye on the door to make sure no-one goes in/triggers the sensor)
  4. If the Automation is working, you should get a message + the location should be freed up/end (reservation end time is changed)
• Send a message when utilization exceeds maximum capacity :

  1. Select a location for which the above Automation scenario is configured

  2. Make sure that

     1. utilization is measured correctly in this room/location (see Quality Assurance on motion & headcount sensors)

     2. Setting the capacity and thresholds of spaces is configured in Workplace back-end Studio
  3. Make a reservation for the selected room/location on any of the touch points
  4. Enter the location with more people than are allowed as per the Setting the capacity and thresholds of spaces configuration
  5. If the Automation is working, dedicated (group of) user(s)) (as defined in the Automation) should get a message
• Send a message to confirm an upcoming meeting (and cancel if ignored) :

  1. Select a location for which the above Automation scenario is configured

  2. Make a reservation for the near future for the selected location on any of the touch points, with a user that is configured with as per the Automation requirements (for example phone number and/or e-mail address of the reservation responsible needs to be configured)
  3. If the Automation is working, you should get a message

     1. upon confirmation, the reservation continues to exist

     2. upon cancellation, the location should be cancelled (reservation object receives flag "cancelled")

What if the sensor stops sending data?

The location must have at least one sensor data reading/heartbeat for the past 24 hours in order to be taken into account during execution of no show rule:

• if we've received a data reading/heartbeat from a sensor in the last 24 hours, we assume the sensor is still working (maybe it's just a bad connection with the gateway): the no-show rule will be executed. In this case, it’s most probable that the sensor did not confirm any occupancy, ie that the last data known to Workplace is “not occupied” and therefore the reservation will be cancelled
• if the last data reading/heartbeat is more than 24 hours old, we assume the 'not occupied' status isn’t reliable, and the automation won’t run: in that case, the reservation will stay alive, no matter what's happening in the room (since the sensor there isn’t providing that information to Workplace)