Development Plan

The Development Plan (an individual development plan, or IDP) is where each person writes down what they will develop, as actions with due dates, and follows the plan through to the end, instead of it being written after the review and forgotten in a drawer. The direct leader approves the plan and follows the team; the management team sees how many people have a plan and how many are behind, leader by leader.

It is a space module in the Planning & HR tab of Add Space. A community can have several Development Plan spaces (for example 2026 plans and Leadership plans), and everything is per space: the plan, the team, the approval queue and the dashboard. Who creates the space: owner or admin. There is nothing to configure: once created, the app opens the space.

#What it is for

#Who sees and does what

Each person's leader is their Reports to in the org chart. Memberfy works out who can do what at the moment of each action, from the org chart at that moment.

• Nobody else sees a person's plan: for anyone not in the table, it simply does not exist.
• When Memberfy support enters the community (the Enter button), it neither sees nor touches development plans.
• There are no private leader notes: the person sees everything recorded in their plan, including the return note.
• The person needs access to the Development Plan space to have a plan in it.

Because the direct leader approves the plan, only the owner and the admin change who reports to whom in the org chart. Moderators and finance see the leader and keep organizing groups. See Groups and org chart.

#How it works

#The space's tabs

The tabs show up according to what each person can see: someone who leads nobody sees only My plan.

The tabs are grouped in two modes. Whoever has a management view (leads someone, approves plans or sees the dashboard) opens the space in Manage, with Show: My team, To approve and Dashboard (those the person can see) and the plan cycle bar; Mine is My plan. Whoever has no management view sees only My plan, without the switch.

#The plan

Each action has a Progress: To do, In progress or Done. The plan's Progress counts the done ones ("3 of 5 done (60%)").

An action is Overdue when its due date has passed in the community's time zone and it isn't done. Nobody marks it: Memberfy works it out on the spot, and an approved plan shows "Approved, with 2 overdue actions."

#From draft to completed

1. Draft. The person builds the plan (Save draft). The draft is visible to them, their leaders and the management team, and can be deleted.
2. Send for approval. It needs at least one action. The direct leader gets the notice; without a leader, the owner and the admins.
3. Approve or Return. Whoever approves decides. Return asks for a Note to the person (required): the plan goes back to draft and the person sees the note ("Returned by Ana"), adjusts it and sends it again.
4. Approved. The person updates the progress of the actions. Changing only the progress never asks for a new approval.
5. Complete. The person or whoever approves completes the approved plan, even with open actions, which stay as they were. The plan moves to History and the person can create another one. An approved plan isn't deleted: it is completed.

One active plan per person in each space. Draft, awaiting approval and approved all count as active; to create another one in the same space, complete the current one.

#Changing an approved plan

The form warns beforehand: "This plan is approved. Changing the period or the actions sends it back to the leader for approval; changing only the progress does not." The previous version isn't kept.

#The leader creates a report's plan

In My team, Create plan next to a direct report without a plan. The person gets the notice, sees the plan and can adjust it before sending it for approval; sending it is still up to them.

#If the leader changes

The decision always belongs to the direct leader at that moment. If someone's leader changes while their plan is awaiting approval, the decision moves to the new leader, who gets the notice.

#The dashboard

One row per Direct leader (and No leader), with People, With a plan, Awaiting, Approved, Not started, Overdue and Completed. Delays are counted up to today, in the community's time zone. The owner, the admin and finance see everyone with access to the space; a leader sees their team, direct and indirect reports.

#E-mails

The Development plan category of E-mails from this community, on by default, has four notices, never with the plan's content, only the notice and the View the plan button:

#The company cycle

A cycle gives the whole company the same deadline, with reminders. The owner and the admin open it in Manage PDI cycle › Open cycle, at the top of the space:

• One open cycle per space. The active plans of the people in the audience join the cycle, and so do those created while it's open.
• People in the audience see the cycle's name and deadlines at the top of the space, with where they stand: "Send your PDI by 11/30", "Your PDI for this cycle has been sent." or "The deadline passed: send your PDI as soon as you can".
• A leader sees their team's cycle at the top of the space, with the deadlines and the adhesion of the people below them, even when they aren't in the audience themselves.
• Edit changes the name, deadlines, audience and reminders. Close cycle stops the reminders; the plans stay as they are, linked to the cycle, and the adhesion stays on the dashboard. A closed cycle doesn't reopen.
• Reminders. Opening sends nothing right away. On each reminder day, whoever is in the audience and hasn't sent receives "Submit your development plan for …", and a leader with plans of the cycle to approve receives "Development plans of … are waiting for your approval". Nobody gets two on the same day. The e-mails belong to the Development plan category of E-mails from this community, with that category's unsubscribe link in the footer.
• Adhesion. On the Dashboard tab, Cycle adhesion shows, per direct leader, People, Sent, Approved, Not sent, Late to send and Late to approve. The owner, the admin and finance see the whole audience; a leader, only the people below them.

#Action linked to a course

When creating or editing an action, the Community course (optional) field links the action to a course the person can see. The action then shows the progress ("3 of 8 lessons (37%)") and See course; someone not enrolled yet sees Enroll, which leads to the course (a paid course follows the usual purchase). When the person completes the course, the action is marked Done on its own, and they can reopen it. The leader and the team who read the plan see the same progress. If the course goes away, the action loses the link, with a notice.

#Action created by a workflow

A workflow with the Add a PDI action action adds an action, with a deadline, to the person's active plan (for example, after a review result); with no active plan in the space, it creates a draft with it. The action shows "Created by the workflow …", with the workflow's name, and follows the same rules as any action.

#Step by step

#Create the space

Role: owner or admin.

1. Add Space › Planning & HR › Development Plan.
2. Give it a name (e.g. 2026 plans), the section and who has access.
3. Save. The app opens the space.

#Build and send your plan

1. In the space, My plan › Create my plan.
2. Title, Start and End.
3. Add action for each action: title, description (optional) and Due date.
4. Save draft to continue later, or Save and send.

#Approve or return

Role: the person's direct leader, owner or admin.

1. In To approve, open the plan.
2. Approve, or Return with a note on what needs to change.

#Follow up and complete

1. In My plan, change each action's Progress as you go.
2. At the end of the period, Complete.

#Examples

A company's yearly plan. Space 2026 plans, open to everyone. Carla builds hers with three actions (Take the communication course, due 04/30; Present at the all-hands, 06/30; Mentor an intern, 10/31) and sends it. Diego, her leader, returns it with the note "Add an English action"; she adds it and sends it again; he approves. In May, the HR dashboard shows Diego's team with one overdue action.

The leader starts the plan. Diego creates, in My team, the plan for Bruno, who has just joined. Bruno gets "Diego created a development plan for you", adjusts a due date and sends it; Diego approves.

The person changes an approved plan. Carla changes an action's due date: the plan goes back to Awaiting approval and Diego gets the notice. If Diego made the same change, the plan would stay approved.

#Through the assistant (MCP)

The development plan tools are in Tools · Members › Development plans. The cycle (get_current_development_cycle for anyone; list_development_cycles and get_development_cycle for the owner, the admin and finance; create_development_cycle, with dry_run to see first how it looks and who gets the reminders, update_development_cycle and close_development_cycle, which asks to confirm, for the owner and the admin; get_development_cycle_adhesion for the team and for a leader, about their team) and course_id on actions, with the course progress. See the recipe Open the PDI cycle and follow the adhesion.

#Common errors and how to fix them

#Frequently asked questions

Does the indirect leader approve? No. They see the plan and their team's dashboard, but the direct leader (or the owner or the admin) approves.

Can I delete an approved plan? No. Only a draft is deleted; an approved plan is completed and stays in the history.

Does completing with open actions lose them? No. They stay as they were, done or not, in the history.

Does a moderator see the plans? Only those of the people they lead in the org chart.

#In the API

The space is module: "developmentPlan", and a community can have several. The routes are under /api/development-plans, with the X-CommunityId and the spaceId (required when there is more than one space): GET and POST /api/development-plans (scope: mine, team, toApprove or all), GET /api/development-plans/team, GET /api/development-plans/dashboard, GET, PUT and DELETE /api/development-plans/{id}, POST /api/development-plans/{id}/submit, /approve, /return (with note) and /complete, and the actions at POST /api/development-plans/{id}/actions, PUT and DELETE /api/development-plans/{id}/actions/{actionId}. Each plan carries canEdit, canSubmit, canApprove, canReturn, canComplete and canDelete; anyone who can't see it gets 404, and a second active plan, 409 (activeExists).

Cycles and courses: GET /api/development-plans/cycles/current, GET and POST /api/development-plans/cycles, GET and PUT /api/development-plans/cycles/{cycleId}, POST /api/development-plans/cycles/{cycleId}/close and GET /api/development-plans/cycles/{cycleId}/adhesion. Opening, editing and closing belong to the owner and the admin (403 cycleDenied); listing and viewing a cycle, to finance too (403 cycleTeamOnly); a second open cycle in the space returns 409 (cycleOpenExists). Actions take courseId (null unlinks) and bring course, with the progress.

#Related

• Groups and org chart
• Feedback
• Modules
• E-mails from this community
• Tools · Members › Development plans