Use “Show a booking” in Recued. Reads one provider record booking and the people attending it. The booking's own fields are labelled from the provider response; the attendee list is a separate read, because the booking carries attendees only as an unstructured data.
Show a booking
Use “Show a booking” in Recued. Reads one provider record booking and the people attending it. The booking's own fields are labelled from the provider response; the attendee list is a separate read, because the booking carries attendees only as an unstructured data.
Complete workflow
Booking Desk
4 pinned recipes
Use Booking Desk in Recued for calcom, bookings, appointments, and scheduling. It includes 4 ready-to-run workflows and 1 related pack in one install.
You are viewing one recipe in this workflow. Installing it opens the complete pack so its other recipes and background automations arrive together.
Use “Today's bookings” in Recued. Reads today's provider records bookings, newest start first, with who is attending each one. It reads information without changing data in the connected service.
Use “Ask to move a booking” in Recued. Asks the attendee to pick a new time for one booking.
Use “Record a no-show” in Recued. Marks the attendee of one booking as absent in provider records, so the no-show is on the record rather than in your memory.
Why the attendees are read twice
Cal.com describes the same people two ways, and the difference is the whole point of this view.
The booking record carries attendees as an opaque JSON blob — the pack declares it type: "json", so this view can only tell you how many there are. The named list is a separately declared entity (booking_attendee), fetched by its own call, where each person's name, email and phone_number carry their PII classification.
So the top block shows the booking as the pack declares it, and the table below shows the people as the pack declares them. Nothing here is labelled by hand.
Acting on it
Both actions open the run form with the booking already filled in, so you edit the reason the attendee will read BEFORE anything is sent — and the operation itself is approval: ask, so it pauses again for you after that. Two gates before a message leaves the server.
⚠ This is a live read. It shows Cal.com as of now, and fails rather than showing you something stale if the connection is down.
⚠ Attendee contact details are real personal data. They are shown to you, the owner, and are never included in a public status page — a visitor-facing surface has its own, narrower field ceiling.
How it works
Inspect the data fetches, transforms, gates, and output this recipe runs.
Process (18 steps)
uid
trim
Trim whitespace from setting booking uid
uid_present
compare
Check if uid has data
uid_guard
guard
Stop if uid present equals
booking_read
?
booking
default
Apply default
found
compare
Check if booking uid has data
found_guard
guard
Stop if found equals
attendee_read
?
attendees
default
Apply default
attendee_count
count
Count items in attendees
attendee_rows
map
Extract from each item
attendee_table
to_table
Format results as a data table
calendar_read
?
links_raw
default
Apply default
links_fixed
map
Extract link from each item
calendar_links
map
Extract from each item
actions
default
Apply default
card
to_summary
Format results as a summary card
Settings
Configurable at install. Defaults shown — change them anytime in Recued.
calcom
setting
=
booking uid
setting
=
[object Object]