-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Email based workflow systems #28
Comments
For folks familiar with this use case, do these workflow systems direct people to different URLs on a single site or potentially direct them to different sites altogether? For example, the workflow is completely contained in URLs on customer1.example vs contained in URLs spread across tool1.example, tool2.example, tool3.example, etc. |
Note, the partitioning idea in #42 could perhaps support this use case, but only if the email workflow is always redirecting to the same destination site. If its redirecting to different destination sites then the partitioning would not help. |
One use case discussed at TPAC that might break with bounce tracking mitigations is email based workflow systems. Consider:
Here the bouncer is being used to implement a business workflow solution for a customer.
Since the user never actually interacts with saas.example/bouncer, however, our mitigations will end up deleting the cookie. This will break the workflow.
Current work arounds are:
a. Add an interstitial explaining to the user that saas.example is managing the workflow for the customer and solicit an interaction. (Adds user friction.)
b. Host a version of bouncer under the customer.example domain either via a CNAME or on-premise installation. (Adds integration costs for SaaS provider and customer.)
We should consider other ways we can support this use case.
The text was updated successfully, but these errors were encountered: