Objectives - Redesign configuration

Audience and prerequisites

Campaign and form administrators configure performance objectives in a nextgen form and select that published form in an interview campaign. Verify the nextgen workspace, form-creation/update rights, campaign access, participants and assigned evaluators. Form publication and campaign activation are separate actions. The Forms configuration guide covers form lifecycle and translations; Interviews configuration covers campaign phases and visibility.

Configure the question

1. Open Performance → Forms [new] and create or edit an authorized form. Add the performance-goals question and enable the past and/or future step offered by the builder.
2. For each enabled step, set whether answering it is mandatory. Review the effect on both participants before publishing.
3. Set whether employees and reviewers may create objectives. In the checked builder, making an enabled step mandatory forces both creation switches on and disables their separate editing while the mandatory condition remains.
4. For an enabled past step, set the period duration and choose months or years. The checked editor requires an integer of at least one and a unit. The period is used for automatic past-goal import; verify actual results with the target data.
5. Review question wording, evaluator wording where offered and content languages. Save, preview and publish the form. Select it in the intended campaign and configure dates, preparation sequence, role assignments, answer visibility and signatures separately.
6. In a test campaign, complete past and future paths as both roles. Check goal creation, import, key-result assessment, approval, weights and required-answer messages before launch.

Setting	Scope and effect	Evidence / limitation
Past / future step	Selects the objective steps to include.	Verified in code: builder schema and mapper. Confirm available controls in the deployed revision.
Required for each enabled step	Governs whether that step must be answered.	Verified in code: builder uses separate past/future flags; participant validation is step-specific.
Employee / reviewer creation	Controls creation by role.	Verified in code: mandatory setting forces both switches on in the checked client. This is not proof of every server authorization rule.
Past period	Positive duration and month/year unit.	Verified in code: required when past is enabled. Do not infer a tenant-wide default.
Campaign phase and sharing	Determines when participants can work and see contributions.	Verified in code: campaign and form controls are separate. Test their combination.

Changes and troubleshooting

A form used by running, completed or archived campaigns may be read only. Review usage and duplicate into a new form version when appropriate; do not assume historical answers migrate. For missing goals, check the past period, participant and import availability. For rejected completion, inspect required steps, pending approvals, key-result assessments and weights. If a section renders blank, report it with campaign, role and step; do not bypass validation.

Evidence and limitations

Verified in code: smartmobility-nextgen-front/src/modules/ModuleConfig/Campaigns/modules/FormBuilder/components/Builder/BuildPerformanceGoals.vue, domain/formBuilder.frontend.schemas.ts, domain/formBuilder.mapper.ts; smartmobility-nextgen-back/src/Domain/V2/ReviewForm/DTO/Review{Past,Future}ObjectiveQuestionDTO.php. Observed in application: the participant paths described in Functional were exercised on the fake test platform. The complete configuration panel and defaults were not observed in this session. Legacy period settings and question types use a different model; see Legacy configuration. No settings were changed for this documentation.