Edusign connector

What is sent, and what is not

The connector first sends the sessions. Each one becomes an Edusign course carrying the Omniscol identifier as its external reference. That is what later makes it possible to find it, update it or delete it without keeping a mapping table on the side.

Calendar events can join them if you ask for it: a lecture, a thesis defence or an induction day is signed like anything else. They have their own section further down.

Teachers and groups can be sent too, in two ways: created on the fly during the session export, if you enable that option, or synchronised in bulk from the Entity export tab, Omniscol then being the reference. Students are never pushed automatically: they are only sent on a manual trigger, for the reasons explained below.

One important point: do not mix two ways of creating the sheets.

Either your sessions are born in Omniscol, and the connector creates them in Edusign: the most coherent choice if your timetable moves, since corrections, absences and substitutions will follow.

Or you create courses directly in Edusign. That is possible, but those courses then live outside Omniscol: the connector will leave them alone, and your planning changes will not reach them.

The safest is to decide from the start on which side your sheets are born, then stick to it. That is what keeps you from ending up with two versions of the same session.

Before the first export

For Edusign, a session without a teacher is unusable: it needs to know who carries the attendance sheet. What follows hangs on one question: do your teachers already have their Edusign account?

They already exist, with the same e-mail address on both sides. Nothing to do: the matching is automatic. This is the most common case, and the reason the address must be filled in and reliable in Omniscol — it is the matching identifier, and it is also the Edusign login. If two teachers share the same address in Omniscol, the connector tries to tell them apart by their names: the section below details what it does, and what can block.

They already exist, but the addresses do not match. That is what association is for: the association screen shows your teachers facing the Edusign accounts, and every association you set is authoritative, ahead of any address matching. Same recourse for the ambiguous cases, when a shared address resists the name tie-break.

They do not exist in Edusign yet. Two options:

• on-the-fly creation — tick remote creation in the system configuration, Systems configuration tab, and the connector creates each account the moment a session needs it;
• teacher synchronisation — push them all at once from the Entity export tab, and the accounts exist before the first session even goes out, Omniscol being the reference.

On the fly or in bulk, Edusign keeps each e-mail address for a single account. Already taken, the creation fails, and the teacher's sessions with it; shared between two teachers in Omniscol, the connector creates neither — not even the first, which would bind the address to one of the two at random — and their sessions wait until each has their own. Creation is therefore for accounts that are genuinely absent — for a teacher already present in Edusign, stay with matching or association.

One more caution before requesting creation from Omniscol into Edusign: depending on how your Edusign account is set up, creating a user may immediately send them their login details by e-mail. Your teachers would then discover the new tool from the very first export, without having been prepared. If you would rather announce the accounts yourself, check that setting on the Edusign side before launching the export.

If the teacher remains unresolved, the session is not sent. The connector counts it and reports it explicitly: a missing attendance sheet is the kind of problem you never discover at a convenient time otherwise.

Matching by e-mail address

For a teacher with no association set, and whose account was not created by the connector, matching runs on the e-mail address, whatever the first and last names on either side. It must therefore be exact: a wrong address blocks the session, and two swapped addresses would swap the sheets of two teachers.

First and last names only come in to settle a duplicate: two teachers declared in Omniscol with the same e-mail address — a school-office mailbox, an address shared by visiting staff. The connector then compares the names against the Edusign accounts. That is almost always enough: each finds their account, the sessions go out.

Two perfect homonyms on the same address are in all likelihood one person entered twice on your side. The sheet will carry the right name, the right subject and the right class whichever account is picked: the session goes out, and the integration journal records the duplicate, to clean up when convenient.

That leaves the case where no name fits. The teacher may have no account at all, and sending at random would have attendance signed on someone else's sheet: those sessions stay behind. The export summary gives the names and the address at fault — down to the person who merely creates the duplicate without teaching, and whom you would otherwise hunt for a long time.

The durable way out is to give each their own e-mail address. Until then, associate them by hand: once the association is set, the identifier is authoritative.

Filtering by campus

A campus is an organizational notion: it groups classes within the account, independently of sites and rooms. If your school declares any, you can send only the sessions of some of them. The choice sits in the Entity export tab, under the course sessions.

A session goes as soon as at least one of its classes sits on a selected campus: a course spanning several campuses is therefore sent once, as it should be. A class with no campus is not kept once a selection exists — you said which campuses you get signed, and it is not one of them.

Narrowing the selection afterwards withdraws from Edusign the sessions that no longer belong there, except the ones that have already happened: their signatures are acquired. Ticking nothing means sending the whole school.

The export horizon

Edusign is there to get upcoming sessions signed. A past session no longer needs to be prepared for signing, and Edusign locks it.

The horizon is set in the system configuration, as a number of days backwards and forwards around today. In practice a few days backwards is enough: they only serve to catch a correction made just after the session.

A session that falls out of the horizon is never deleted. It took place, Edusign holds its signatures, and those cannot be rebuilt. Only a session genuinely deleted in Omniscol is removed from Edusign — and only if it has not happened yet.

Real time and catch-up

Two mechanisms coexist, with two different roles.

Real time sends every change as it happens. This is the normal mode: it keeps Edusign up to date almost immediately. But treat it as a convenient channel, not an absolute guarantee: a request can fail, a process can restart.

The scheduled full export reconciles both sides regularly. It sends the whole horizon, reads back what Edusign holds, then deletes the sessions that no longer exist on your side but that real time missed. It is the safety net: without it, a network incident or a restart would leave a silent divergence.

Students

Students are only sent on a manual trigger, and with particular care.

Edusign can only match a student by the external reference we have put on them — not by their e-mail, not by their internal identifier. A student already present in Edusign without that reference is therefore out of reach: sending them would create a second record carrying the same address.

So the connector chooses to do nothing rather than create a duplicate. It first reads the Edusign students, creates only those genuinely absent from it, and leaves the others untouched. Students with no e-mail address are set aside the same way: they cannot be matched by any means. When the trigger finishes, a summary lists by name those that were left aside, with their identity on both sides, so you can decide case by case. The activity journal keeps a record of it.

In practice, students are only needed if you want named sheets. Signing works without them as soon as the session carries its teacher and its group.

Events

A lecture, a thesis defence, a mock exam: anything placed in the calendar without being a teaching session can be sent to Edusign as well. Events have their own section in the Entity export tab, just under the sessions, with their own filters and their own sending policy.

An event carries the same information as a session: its date, its participants, its room. Invited people who are teachers carry the sheet; invited classes and groups form its audience.

You do not have to send them all. The connector filters on the tags you put on your events — see One-off events: send only those carrying a given tag, or the other way round, send everything except those carrying one. Exclusion always wins, which allows the most convenient rule: send everything, except what you marked no signature.

When an ERP is already in the picture

The simplest case is a school managing its sessions in Omniscol, then getting them signed in Edusign. That is the connector's most direct use case.

In institutions already built around an ERP such as Aurion or Auriga, the architecture is generally a star centred on that ERP. It sends its reference data to Omniscol — teachers, rooms, subjects, groups, sometimes students —, and Omniscol sends back the sessions it has produced.

From there, Edusign most often plugs into the ERP rather than directly into Omniscol. Depending on the chosen setup, either the ERP forwards the sessions to Edusign, through an ETL if need be, or Edusign reads them from the ERP on a regular basis.

In that topology, external references do not replace one another: they stack up according to the exchanges to be covered. One and the same teacher can thus carry an ERP reference in Omniscol and, if needed, a separate Edusign reference. In the Entity synchronization tab, each configured system stays associated separately, for the same entities.

Resetting

The purge button removes the sessions coming from Omniscol from Edusign, over the current school year. It touches neither the teachers, nor the groups, nor the courses created directly in Edusign: its purpose is to clean up what the connector pushed, not to wipe the rest of your environment.

Edusign heavily limits the deletion rate: each pass removes a few hundred sessions at most. If any remain, run the purge again — the activity journal reports how many are left after each pass.

What the connector creates in Edusign cannot always be undone in the strict sense: deleting a teacher there is an archival. So enable creation knowing what it implies.