Posted: 29 May 2019 11:50 EDT Last activity: 30 May 2019 11:41 EDT
Pega Survey - Adding a Question from Library
When I add a Question while using the PEGA 'Survey Creation Tool', the question is added immediately to the library and available to be added if required again.
When I add a Question using the 'Question Authoring Tool' and selecting the correct Context, the question (ProgramFocusArea in the below example) is added to the library but is Unavailable to be used in the Survey.
The question is visible but greyed out. Cannot be selected to add to the survey.
What is the point of making it available for isplay but not be made available to be added?
HOW do we make questions that are added DIRECTLY to the Survey Repository be made available for addition to individual surveys?
The rule displaying the Libray Questions is an OOTB rule 'pyAddToLibrary' in class Data-Rule-Summary and the 'Add' functionality is disabled because property ' .pyIsEnabled = false ' evaluates to true. I am using PEGA 8.1.
Is there anything I need to do explicitly, to enable the question AFTER it has been added to the Question Library? What is the point of adding a question to a Survey Library if I cannot add it to my survey but it is only 'visible' in the Library?
Hi, You need to create a property and map it to the question that you have created from question authoring tool. Only then 'Add' will be enabled for that particular question. For question created from survey authoring, property is created and mapped to the question automatically due to which Add is enabled for that question. This is enhanced in later release to enable 'Add' even if question doesnt have property mapped to it and created property when user adds it to the survey.
This assumes that a property is ALREADY available for use/or created and a person writing a NEW question is intelligent enough to link the (already created) property to the new question. It is difficult to explain to a Survey Writer or Survey Editor (who is completely NonTechnical) what you just explained. \
(Just a few observations which would make the survey functionality even more user friendly that a non technical person or a 'citizen developer' will be able to use it.)
The UI for creating a new question also does NOT make mapping a property a REQUIRED field which will eliminate some of this confusion and also the drop down for mapping should show the property .pyShortDescription instead of property .pyPropertyName. which will be more meaningful to a survey author.
Either force mapping of a property or the creation AND mapping of a property, when a new question is created.
I think there might be another approach that would drive context into the property naming and provide some much needed guidance to the survey author.
Currently, when a new question is added in Survey conversation mode, a new property is added behind the scenes as noted above. In addition, the question is named based on the verbiage of the question.
However, when adding a question to the library, a question name can be provided in addition to the verbiage of the question itself.
If this question name were exposed in the conversation mode as well, you could use that name as the basis for naming the associated property. This drives context into the data model so that a person doing reporting based on the survey has a better idea as to the definition of the properties.
As far as requiring the property mapping at the time of library question creation, this assumes that the property is known when the question is created. In the field, I have seen instance when the data model is being created in parallel to the creation of the library questions. What would be helpful is something that enforces the requirement at the time that a library question is added to a survey. Rather than not allowing it, make it possible to require the property mapping at the point in time that the question is added to a survey.
It also suggest the ability to report on library questions by showing those mapped to properties and those not mapped to properties. I am sure this could be done at implementation time, but it seems like a fairly generic need for those using Survey and might be a valuable addition to the OOTB platform.