Error while using pyMobileSnapStart to open a work item


We are trying to implement a solution for opening a workitem from an email. On click of this link we have to open the portal and the work item in the context should be loaded.

To achieve this:

1. We have tried using 'pyMobileSnapStart' as per the instructions provided in

However, when we did this, we get to see the following error :

2. I have also tried using worklink correspondence provided OOTB to open the work item using the inskey. But this is working only for the developer portal URL and for the customer portal URL it throws the following error:

So, can some one help me identify the issues here. I have attached the stack trace for scenario 1.

Appreciate your help!


Keep up to date on this post and subscribe to comments

June 26, 2019 - 4:13am


Can you try tracing it? It looks like the context is wrong because the system is searching @baseclass level.

June 26, 2019 - 6:09am
Response to MarcLasserre_GCS

Hi Marc, Unfortunately i am not able to trace this request. 

This activity is present in the baseclass. So, i am expecting it should pick it up from there. I have checked the access group of this operator to find out if he had access to that particular rule set and it has that. So i am just trying to find out what else could be the problem. 

Thank you

June 26, 2019 - 10:27am
Response to shanmukharaos


What product version are you using?

June 26, 2019 - 10:48am
Response to MarcLasserre_GCS

Marc, We are on PEGA 7.1.8. 

Just to provide more information, following is the format of the URL i am trying to invoke:'.pzInsKey'

Do i need to add any other paramters?


June 26, 2019 - 11:12am
Response to shanmukharaos


I guess the question is, can you follow those 7.3 instructions from your 7.1.8 system.

June 26, 2019 - 1:04pm
Response to MarcLasserre_GCS

Would it be different for different versions of Pega. 

If we can not use pymobilesnapstart, any idea work-open activity used as part of worklink is throwing the error in option-2? 

July 10, 2019 - 5:38am

We still have this problem. Any suggestions on how to resolve this.