Appointment

Hi Joana,

Seems like you understood it correctly. Worth mentioning that offer expiry datetime will release the provided slots if any response (offer select or reject) is not provided.

Also, to happen a re-booking in non-blocking type, another user need to confirm the same slot before you select it. So this is depending on the frequency of appointment requests coming in.

@martinnc, do you have any info that could help on the above question? Thank you in advance 

@AndreiaLeitao note that the blocking will expire after the set timeout. Blocking is actually the most used approach. The Non-blocking feature were introduced later in order to handle activities with dependencies better. So if you do not use such dependencies it should work fine with the blocking.

@martinnc , what we understood is that the expire time doesn’t work if the integration is coming from FSM to PSO. Is that still the correct behavior?

Then, from our understanding the Rejection interface needs to be handled by the external system if they don’t want to confirm a returned slot. Could you please confirm? @martinnc , @Sajith Anushan 

Thanks for the support :)

Hello,

from our understanding it is possible to use the following REST APIs both for appointment templates that are blocking and unblocking:

• perform_threesixty_appt_offer_accept
• perform_threesixty_appt_request​

Is this correct?

Also what is the scenario where the perform_threesixty_appt_offer_reject REST API is used?

 @martinnc do you have any information related to this?

thanks

@joana.m.machado I can’t say I know much related to rest calls in FSM, but I would say this should be feasible. Could imagine though the polling broadcast reference might be a challenge.

@Rob Oldenburg anything you can confirm?