There is a user (anonymous) connected to you anonymous session.
But you should be able to use [System.owner='[%CurrentUser%]'] as Xpath constraint for your antity access for the anonymous user role.
Your comment helped me understand what you are trying to accomplish.
Since all of the information in the first registration step is stored in the database (including the users email), you could include the user’s email as a query parameter in the deeplink you email to the user. Then when they click on the deeplink, you will get their email address which you can use to look up information they entered previously.
Another thought: since you are gathering bank info, which you want to provide a high level of security for, including the email address in the deeplink would open you up to hackers. Alternatively, you might want to send a random hash in the query string and use that to look up the users information. You could also, depending on the security regulations in your country, ask users to confirm their email address after they click the deeplink, to provide some assurance that it is the person who entered the prior bank info. For more security, you could have the the user enter bank info after they create a user account – however, I am not sure if this fits your use case.
Hope that helps,
Could you set it up this way:
In step 1 – when the user is entering initial registration info, you can set the RegistrationInfo_Session association when the user initiates registration
In step 2 – after the deeplink, you can set the association in the deeplink microflow
Xpath on this entity is as follows:
Note: I haven’t tested this – but think it should work.
I would not try to accomplish this entirely with anonymous users. From my perspective, at the point where a user enters his basic info (name, email, etc.), you should create an Account for him with a specific user role or flag that designates that his setup isn’t complete. On that account, add a random hash. Then use that random hash as the way back into the account. This can be done via a custom request handler that accepts this hash or ”magic token” and starts a session for that user.
I once created a module for two-factor authentication, and one of the by-products was a request handler that handles magic links like this: