활동이 없어 이 대화는 잠겼습니다. 새 게시물을 작성해 주세요.
활동이 없어 이 대화는 잠겼습니다. 새 게시물을 작성해 주세요.
Hello,
With Campaign Classic we would like to send a special offer email to the customer who visits some products in the website. But we do not want to send the email every customer on every product, we will have a business logic like if the product's price is higher than $100 and user is a VIP user etc. As I see, transactional messaging does not allow to run business rules like above. Is this approach can be done with workflows? I can trigger the workflow via api when a customer visits the product's page and then some business logic happens, if user and product is eligible for special offer then email is sent. Is this approach is fine with performance aspect? Should my workflow run always in order to accept external signal?
Thanks in advance.
해결되었습니다! 솔루션으로 이동.
It's more efficient to batch the work. An external signal can be used instead of a scheduler, though requests should still be captured outside the workflow and staged in a table, for reliability and auditability. Calls to the signal can be made by a custom endpoint as a single user-facing api; or users can call 2 ootb api's, one to write the request and one to have the workflow pick it up.
Hi,
Yes, all of that is correct. Instead of external signal, spool requests to a staging table and poll it every 5 minutes, for a 'near-realtime' solution.
Thanks,
-Jon
Hi,
Can you provide more details regarding option #1 (triggering a workflow)?
Workflow isn't triggered, it's on a 5-minute scheduler. Requests are recorded to a table the workflow polls, either via ootb crud endpoint or a custom endpoint.
I'm referencing the option to trigger/call the workflow from an external system and NOT running it through the scheduler.
조회 수
답글
좋아요 수
It's more efficient to batch the work. An external signal can be used instead of a scheduler, though requests should still be captured outside the workflow and staged in a table, for reliability and auditability. Calls to the signal can be made by a custom endpoint as a single user-facing api; or users can call 2 ootb api's, one to write the request and one to have the workflow pick it up.