Enrollment Push

The enrollment push sends deal and person data from Pipedrive to Campus Cloud SIS. It is initiated by the user from the deal sidebar panel.

Workflow

flowchart TD A["Click 'Push to Campus Cloud' in deal panel"] --> B[Fetch deal from Pipedrive] B --> C[Fetch associated person from Pipedrive] C --> D[Resolve field mappings and enum values] D --> E[Check for existing student by email — GetStudent] E --> F{Student found?} F -- Yes --> G[Update student — ModifyLead] F -- No --> H[Create student — AddLead] G --> I{Application fields configured?} H --> I I -- Yes --> J[Post application fields — PostApplicationFields] I -- No --> K{Custom fields configured?} J --> K K -- Yes --> L[Post custom fields — PostCustomFields] K -- No --> M[Post activity note — PostActivity] L --> M M --> N[Return result to panel]

Step-by-Step

1. User Action

The user clicks the Push to Campus Cloud button in the deal sidebar panel. The panel sends a POST request to /api/campus-cloud/push with the current dealId.

2. Fetch Deal and Person

The server fetches the deal via the Pipedrive v2 API, then fetches the associated person using the person_id on the deal. Both responses are normalized for consistent field access.

3. Resolve Field Mappings

For each mapping in the enrollment map (person, deal, application, custom, static), the server:

  • Looks up the Pipedrive field value on the person or deal object using cached field definitions.
  • Resolves enum/set fields from numeric option IDs to human-readable labels.
  • Applies enumValueMap overrides to translate Pipedrive labels to Campus Cloud values.
  • Collects static values that are sent with every push.

4. Student Lookup

The server calls GetStudent with the person’s email address. If a student ID is returned, the existing record will be updated; otherwise a new lead is created.

5. Create or Update Student

Scenario API Call Result
Student not found AddLead Creates a new student record and returns a StudentID.
Student found ModifyLead Updates the existing student record with the mapped fields.

If AddLead fails to return a StudentID, the push is aborted and an error is returned to the panel.

6. Post Application Fields

If the enrollment map includes application field mappings, the server calls PostApplicationFields with the student ID and an array of { FieldID, Value } pairs. These are Campus Cloud application-level fields identified by numeric ID.

7. Post Custom Fields

If the enrollment map includes custom field mappings, the server calls PostCustomFields with the same structure. These are Campus Cloud custom fields identified by numeric ID.

8. Post Activity Note

An activity note is posted to the student’s Campus Cloud record via PostActivity, recording that the push originated from the specific Pipedrive deal.

9. Result

The server returns a JSON response to the panel with:

  • success — whether the push completed.
  • studentId — the Campus Cloud student ID.
  • activityLog — an array of actions taken (addLead/modifyLead, postApplicationFields, postCustomFields, postActivity) with success/failure status for each.

The panel displays the result to the user.

If some fields fail to post (e.g., an application field ID is invalid), the push does not abort entirely. The activity log will show which steps succeeded and which failed, so you can diagnose issues without losing the successful parts of the push.

The push requires an authenticated Pipedrive session (it uses requireAuth middleware). It cannot be triggered from a webhook or automation — it must be initiated by a logged-in user viewing the deal panel.

Previous Overview Next Overview