Career plan — configuration guide

Prepare employee access, manager visibility, target horizons and job data before rolling out career plans. Read the functional guide for the employee journey and technical guide for contracts and dependencies.

Audience and access

Company administrators or implementation teams maintain activation and target horizons. HR maintains reference jobs and profile data; managers review only profiles within their authorized scope.

Observed in application: PS Testing, prescribed test account, 23 October 2026. Personal-space plan creation and target saving worked. The same account could enter Manager area, but the Career Plan parameters page denied access. No tenant settings were changed. Configuration steps below are Verified in code, not a successful administrator walkthrough.

The page displays an authorization denial instead of career-plan settings. Return to the normal navigation and ask an authorized administrator to review access; no configuration values are visible here.

View full size

Activation and dependencies

Setting or prerequisite	Scope and effect	Evidence
careerplan_fo	Employee career-plan tab visibility in the internal-job submenu.	Verified in code: InternalJobTabsEnum, InternalJobSubmenuService.
my_career_v2	Standalone career-project list/detail route generation; when disabled, controllers redirect to the internal-job home. This is a legacy feature generation, not a nextgen migration switch.	Verified in code: internal-job UserPlanController.
careerplan_bo	Manager employee-profile career-plan subsection.	Verified in code: CareerPlanSection::loadAccess.
bo_hide_carriere_tab	Hides the manager career tab when enabled, before subsection access/data loading.	Verified in code: CareerPlanSection.
Company job descriptions and locale	Supply the job selector. Missing or unsuitable reference data can leave selection empty.	Verified in code: controller queries JobRepository.
Target horizons	Company-level start/end intervals in years; standalone add capacity is one job per horizon per plan.	Verified in code; one 0–0 option observed.
Stored user/job matching	Supplies displayed percentages; no matching record yields zero.	Verified in code: UserPlanJob::getUserPercentageMatching.
job_matching	Controls the explanatory job-suggestion text on the checked standalone detail template. It is not the plan-count setting.	Verified in code: detail template.

The main/B/C three-plan limit is a code constant, not an administrator field found in the inspected parameters screen. Actual tenant feature-switch values and their inherited/default resolution were Not verified; do not infer them solely from a visible tab.

Configure target horizons

The code-defined company configuration route is /company/account/setting/mycareer. Its template is titled My Career Parameters and contains Intervalles d'une année cible, Ajouter une année cible, Démarrer, Fin, and Enregistrer.

1. Use an account authorized for the company parameters. The checked controller requires a school record associated with the current user and no parent school; a regular manager is insufficient.
2. Record the existing intervals and identify plans using them before changing anything.
3. Add a target-year row and enter integer start/end values. Repeat for each intended horizon.
4. Ensure start is less than or equal to end and that no two rows have the same start/end pair.
5. Save with Enregistrer.
6. In an employee test plan, open Add job and verify the available horizons, save one target, then reopen the plan to confirm the result.

Verified in code: submitted start/end arrays are checked for start greater than end and duplicate interval pairs. Equality of start/end is allowed by the checked condition. Overlapping but different intervals and negative values are not explicitly rejected by that validation loop; use coherent nonnegative intervals as an operational recommendation, not as an asserted server rule.

Defaults, scope and existing data

Verified in code: config/configuration/default_configuration.yml seeds 0–2, 3–4, and 5–8 years. UserPlanTargetDefaultConfigurationService reads the UserPlanTarget configuration and creates records for a setting. These are setup defaults, not guaranteed values for an existing tenant, and the creation loop does not establish an idempotent reconciliation mechanism.

Observed in application: PS Testing currently offered 0–0 years only. That observed tenant option takes precedence over the seed examples when explaining its current UI. No cross-tenant scope or per-employee horizon override was established; horizons are related to the company setting in the model.

Verified in code: unchanged interval pairs are retained when saving; new pairs create records; removed pairs are deleted after existing UserPlanJob references are set to null. Removing or changing an interval can therefore leave existing target jobs without a horizon. Re-entering the old interval later creates a record and does not automatically restore those former references.

Related matching configuration

The same legacy parameters page renders values for job_proximity_matching_green, job_proximity_matching_orange, job_proximity_matching_red, and difference_classification_level. The template handles numeric and complex two-value switches. Their active values, full allowed ranges, inheritance and effect on this tenant were Not verified; do not copy thresholds from examples.

Verified in code: switch values are processed before target-interval validation and before the target transaction. A later interval error must not be assumed to undo all switch changes. Change horizons and matching thresholds separately, with a before/after record and administrator verification.

Rollout, validation and rollback

Validate in a test tenant: employee navigation, manager profile visibility, empty-plan creation, job search, each horizon, saved target count, match display and the full-plan message. Also check an unauthorized account sees the intended access boundary. Existing career targets may feed separately configured job/training suggestions; verify those modules independently.

To withdraw the entry, have an authorized administrator restore the previous activation values. Hiding a tab is not a verified data-deletion mechanism. To roll back intervals, restore the recorded pairs and have an authorized operator assess associations that were cleared; merely recreating a pair is insufficient. No automatic rollback or immediate recommendation refresh was verified.

Problem	Check
Employee tab absent	Employee switch, workspace and labels/translations.
Standalone route redirects	my_career_v2 and intended legacy generation.
Manager subsection absent	Global hide switch, careerplan_bo, profile access and workspace.
Cannot add another job	Number of horizons and occupied horizon slots in this plan.
Save validation error	Start/end ordering and duplicate pairs.
Existing target has no years	Whether its horizon was removed during configuration.
Parameters access denied	Company-root eligibility in the controller; do not bypass it by changing identity.

Legacy, redesign and evidence

Verified in code: these parameters and the observed plan screens are legacy Symfony/Twig. Nextgen-back retains a compatible UserPlanType; nextgen-front contains lexical fallbacks and review/development attachment labels. These findings do not prove a replacement career-plan administrator exists.

Sources in smartmobility-legacy: src/Company/AccountBundle/Controller/SettingController.php::mycareerAction, Resources/views/Setting/mycareer.html.twig and Resources/config/routing.yml under that bundle; config/routes.yaml; config/configuration/default_configuration.yml; src/Service/Configuration/UserPlanTargetDefaultConfigurationService.php; src/Main/ConfigBundle/Resources/config/doctrine/UserPlanTarget.orm.yml; src/Main/SitemapBundle/Enum/Customer/InternalJobTabsEnum.php; src/Company/ProspectBundle/Services/ViewSection/CareerPlanSection.php.

Not verified: administrator save/rollback, deployed switch values, configuration inheritance, recommendation propagation and deployment parity. Client-safe instructions are above; code identifiers support implementation review and contain no credentials or tenant-specific endpoints.