Juba

Hi, coming from Batch, I'd think of the change as moving from a configured extract to requests for particular resources. iSAMS describes Batch as standardised data extraction and REST as real-time access for reads and writes. You don't have to use the write operations just because they're available. For your first test, I'd pick one small read request and check three things: the REST authentication setup for your school, the relevant GET endpoint and its filters, and whether the results are paginated. That last bit matters when you move from a successful test to an actual extract. iSAMS also publishes its own REST example application here: https://github.com/iSAMS/REST-API-Example-App It's a VS2017-era example, so I'd use the current developer documentation for the exact connection details rather than assume an old sample or your Batch API credentials will carry across. What are you using to pull the data — PowerShell, Power BI, Python, or something else — and which data are you trying to get that Batch isn't giving you? That would help narrow this down to a useful first request. No API keys or real pupil details needed.

Hi Char, From how iSAMS’ Reward & Conduct notifications are designed, the built-in notification route is based on the record being created, so I wouldn’t assume it can turn those notifications into one daily or weekly digest. iSAMS can also run reports and publish selected information to the parent portal, so I’d separate the reporting requirement from the notification setting. A practical approach would be: - Filter the records to the chosen date window, and decide whether the window is based on record date or last update. - Group the results by pupil and include only the fields the school has approved for parents. - Deliver one controlled output per family or parent through the system that owns the communication. MySchoolPortal may be able to accept a digest or import, but I’d confirm that before designing around it. - Define how no-record periods, multiple or separated contacts, opt-outs and duplicate contact details are handled. - Never send a single output containing unrelated pupils. If a family has more than one linked child, that needs to be an intentional, verified grouping. SSRS/iSAMS can handle the filtering, grouping and report layout. A standard SSRS subscription uses configured delivery details; if the recipient and report parameters need to change per family, a data-driven subscription or a separate controlled automation layer would normally be needed. That also depends on the school’s SSRS edition, permissions, stored credentials and email/delivery setup. I work with iSAMS/SSRS reporting, and this is the kind of requirement where the data logic and delivery route need to be designed together. If you can confirm what access or integration options you have for MySchoolPortal, I’m happy to help narrow down the safest practical route.