Automations / Revenue access payment → Assignment Portal enrollment / settings

Settings · Revenue access payment → Assignment Portal enrollment

Settings

EnabledSchedule (cron, IST)“0 * * * *” = every hour at :00Write modeAlso requires AP_WRITES_ENABLED=true in the worker env.

Rules

lookbackDays

How many days back (from today, IST) each run searches Revenue. Covers late entries and midnight edge cases; already-seen payments are never re-processed.

ignoredCourseTypes

Revenue course_type values this automation ignores completely (not stored, only counted), e.g. community registrations.

one per lineminPaymentDate

Go-live cut-off (YYYY-MM-DD). Payments dated before this are ignored, so students your team already created by hand are never touched. Empty = no cut-off.

accessInstallmentTypes

Installment type names that count as an access payment (exact, case-insensitive).

one per lineaccessInstallmentPrefixes

Installment type name prefixes that count as access payments, e.g. loan disbursements 'Amount received from …'.

one per lineskipCourseNamePatterns

Regex patterns (case-insensitive). Payments whose course name matches are treated as test records and skipped.

one per lineskipEmailDomains

Student email domains treated as test accounts and skipped.

one per lineapplyTestSkips

When to apply the two test-record rules above. 'auto' = only in production (in QA every record is a test record), 'always', or 'never'.

defaultCountryId

AP country_id used when the phone looks Indian or has no country code (99 = India).

verifyTargetsInAp

Check that the bootcamp/course id exists in the brand's AP listing before creating the enrollment.

requireNameMatch

Also require the AP name for that id to match the Revenue course name. 'auto' = only outside production (QA ids differ from production ids), 'always', or 'never'.

courseBatchStrategy

For standalone courses a batch is mandatory. 'manual' = enrollment waits in NEEDS_BATCH until someone picks the batch in the UI.

Steps in this pipeline

1
Fetch payments source
Call Revenue /api/payments/search for the date window
2
Filter filter
Drop ignored course types, payments before the go-live date, and payments already evaluated
3
Access rules rules
Keep only real access payments; skip test records and invalid rows
4
Map to AP transform
Brand → AP instance, course type → bootcamp/course, verify id in AP listing
5
Duplicate guard guard
One enrollment per brand + student + course
6
Record enrollment record
Store the exact AP request; status depends on write mode
7
Human approval human
A team member approves or rejects (APPROVAL mode)
8
Create in AP external
POST create-enrollment-v2 to the brand's Assignment Portal

How this automation decides

Search Revenue for payments in the date range (today minus lookbackDays → today, IST). Each Revenue payment id is remembered, so a payment is evaluated once.
Ignore ignoredCourseTypes and anything before minPaymentDate.
Skip test records: email domains in skipEmailDomains, course names matching skipCourseNamePatterns.
Keep only access payments: installment type in accessInstallmentTypes or starting with one of accessInstallmentPrefixes.
Map brand → AP instance; offer → bootcamp with bootcamp_id = course_lid; course → standalone course (batch chosen by a human).
Duplicate guard: one enrollment per (brand, student email, course_lid).
Record the enrollment as DRY_RUN / PENDING_APPROVAL / QUEUED depending on write mode. Only QUEUED enrollments are sent to AP, and only when AP_WRITES_ENABLED=true.