I think it's nothing more than just an old legacy design function with the thought that, not knowing what the email will be, that the operator's ID might be their email or close to it.

Thanks.

B.

Hi

I am not sure about the exact answer but I believe it has something to do with setting up the work-party information for originator .

The activity "Validate" maps the property pyEmail1 to pyWorkPartyURI and if we later use any correspondence to send update to ORIGINATOR or OTHER OPERATOR then it can be easily send to their mail id .

Having said that, I believe that the logic holds true till the point we used to auto create operator id with suffix .com ;

In latest release we create the op id without .com so I doubt whether my logic holds true here or not

Others can comment if they are aware of the underlying thought process behind this !

The general format of an email address is [email protected].

So I believe idea was to provide the closest auto-fill since most of the organizations uses localpart as some sort of name combination. Other than that I don't think there was any other thought process as such.

However if someone wants to change this default behavior they can override the NewDefaults activity in Operator class.

But I agree with Santanu and Brendan that this was just done to provide some default value to email id and can be completed from that initial auto fill