Schedule Exchange feature guide
Round-trip write-back for grouped Safran schedules
Send several Safran projects out as one grouped schedule, let them be worked on in an intermediary system, then write the results back into the same source projects automatically, project by project.
In one line: a grouped virtual schedule already bundles several Safran projects into one schedule for sending. This feature lets a follow-up agreement take the data that comes back and write each activity into the exact source project it originally came from, with the checks and warnings needed to keep that safe.
What this applies to
This article is specifically about writing data back into a Safran virtual grouped schedule on the return leg of a round-trip.
- The source on the first leg and the write-back target on the return leg are the same Safran virtual grouped schedule.
- The system in the middle, which is the first-leg destination, can be Safran, P6, Analytics, or any other supported scheduling system. It does not have to be Safran.
- Grouping is by an enterprise-field query today. Grouping by project group, which bundles several schedules, is planned for a later extension and is not covered here.
What this does, requires, and does not do
| What it does | What it requires | What it does not do |
|---|---|---|
|
|
|
What a round-trip is
A round-trip is two linked transfers that share the same grouped schedule.
1. Send out: the first agreement, or predecessor
A Safran virtual grouped schedule, made up of projects selected by an enterprise-field query, is sent as one package to an intermediary system. The intermediary can be Safran, P6, Analytics, or any supported system.
2. Write back: the follow-up agreement
The intermediary system sends the updated data back. Schedule Exchange splits the data by project and writes it into the same Safran virtual grouped schedule, routing each activity to its original source project.
Key terms
| Project / network | A single Safran project or schedule. A grouped transfer spans several of them. |
| Grouped virtual schedule | One Safran schedule that stands in for several projects, chosen by an enterprise-field query, such as all projects where Area equals North. Grouping by project group is planned for later. |
| Predecessor agreement | The agreement that runs first. In this workflow, it is the agreement that sent the data out. The round-trip agreement runs after it completes. |
| Receiving side | The side of an agreement that writes data into a host system. For a round-trip, that target is your own Safran grouped schedule. |
| Intermediary system | The first-leg destination that the data passes through. This can be Safran, P6, Analytics, or any supported system. |
How to set up a round-trip
Set this up on the follow-up agreement, which is the agreement that writes the data back.
- Have a grouped schedule on your Safran connector. Set up or reuse a virtual schedule with a grouping filter on an enterprise field. This is the same grouped schedule the send-out agreement uses.
- Pick the grouped schedule on the receiving side. When you choose the receiving schedule for the agreement, the grouped schedule is selectable. Previously, grouped schedules were offered for sending only.
- Set the frequency to run after a predecessor. Choose Predecessor as the frequency and select the send-out agreement as the predecessor. If you pick a grouped receiving schedule without a predecessor, an on-screen message tells you the agreement cannot be saved until you do.
- Leave Only Include Specified Mappings on. For a round-trip, this receiving setting is turned on by default. It keeps the write-back to just the fields you mapped. If you turn it off, you will be asked to confirm.
What has to be true to save
A grouped schedule on a receiving side is only allowed for a genuine round-trip. All of the following must be true, or the agreement will not save:
- The receiving connector is Safran.
- The agreement runs after a predecessor, meaning frequency is set to Predecessor and a predecessor is selected.
- The predecessor sends from Safran. It is the transfer that first read those projects.
- The receiving connector is the same connector the predecessor sends from, so the data returns to exactly the projects it came from.
If one of these is not met: saving is blocked and the message explains which rule failed, for example that the receiving connector must match the predecessor's sending connector. Nothing is transferred until the setup is fixed.
What happens when it writes back
Each time the follow-up transfer runs, on your client, desktop, or Autonomous Component:
- It reads your current Safran projects live and matches them against the grouping filter, so it uses the projects that qualify right now, not a stale list.
- It writes each activity back into the project it originally came from, matched through Schedule Exchange reference data.
- It restores the original activity code. The grouping prefix that keeps codes unique in the intermediary system is removed on the way back.
- It skips any project that no longer qualifies because its grouping value changed, or because it was deleted, and tells you which ones in the transfer log.
- It handles conflicts per project, using the one conflict-resolution option you set for the agreement. The same choice applies to every project.
About Only Include Specified Mappings: because a write-back edits live source projects, this setting is on by default so the transfer only touches the fields you mapped. Turning it off asks you to confirm. This is a deliberate check, not a blocker.
How each kind of object is handled
A grouped write-back does not treat the package as one blob. It puts each kind of object where it belongs, project by project.
| Object | How it is written back |
|---|---|
| Activities | Routed to the project each one came from, using reference data, with the grouping prefix stripped from the code. |
| Resource assignments | Travel with their activity into that project. New assignments on existing activities are written back too. The referenced resource is ensured in the project first. |
| Resources, calendars, and profiles | These are shared and belong to a calendar, resource, or profile set. Only entries that already exist in the source are updated; new ones are not created. Each set is written once, never repeated when projects share it. |
| Structures / code sets | Each project's existing structures are updated in that project. They are never mixed between projects, and new structures are not created. |
| Links / successors | Links within a single project, including new ones, are written. Links that cross two projects are skipped. |
Fields, codes, and Only Include Specified Mappings
This receiving setting decides how much of each activity is written back.
| Setting | What happens |
|---|---|
| On: specified mappings only | This is the default for round-trips. Only the fields you explicitly mapped are written back. It is the safest choice because it does not touch source fields you did not intend to change. The activity code is only changed if code is part of your mapping. |
| Off: core fields included | Core fields, including dates, code, and other built-in fields, are written back in addition to your mappings. More of what changed at the intermediary flows through. Because this can overwrite more of the source, turning it off asks you to confirm. |
How codes behave: the code follows the same include rule as every other field, matching normal non-grouped download behaviour. With the setting on, the code changes only if you mapped it. With it off, code changes propagate to the source. Whenever a code is written back, the grouping prefix added on the way out, for example 500_112, is stripped to the real source code, for example 112. A code renamed at the intermediary is carried back as the new name.
Conflicts and removals
The write-back edits live source projects, so it uses the same conflict and delete rules as a normal download into Safran, applied per project.
- Conflicts, where a source object changed independently since the last transfer, are resolved using the one conflict-resolution option you set on the agreement. The same option applies to every project in the group.
- Removals follow the normal download behaviour. Something that no longer comes back can be removed from its source project. Choose your conflict option deliberately and review the transfer result.
- If a project reports an unresolved conflict, that project is not written. The other projects still complete, and the conflict is reported for you to resolve.
A round-trip writes to your live source: unlike a one-way transfer to a partner, this changes your own Safran projects. Keep Only Include Specified Mappings on unless you specifically want core fields overwritten, and confirm your conflict option before activating.
Limitations
| Area | What to know |
|---|---|
| Write-back target | The return leg writes back only into a Safran virtual grouped schedule. The intermediary system in the middle can be Safran, P6, Analytics, or any supported system, but the write-back target is always the Safran grouped schedule. |
| Grouping | Grouping is by an enterprise-field query only. Grouping by project group, which bundles several schedules, is planned for a later extension and is not supported yet. |
| Same schedule and connector | The first-leg source and the write-back target must be the same Safran grouped schedule on the same connector. Two connectors pointing at the same server are not interchangeable. |
| Predecessor required | It only works as a follow-up to a predecessor agreement. It cannot be a standalone transfer or a transfer scheduled by the clock. |
| Cross-project links | A dependency link between activities that belong to two different source projects cannot be written back and is skipped with a warning. |
| No qualifying projects | If no project currently matches the grouping query, nothing is written and the log says so. |
What is not written back
The round-trip returns data that can be traced back to an existing source project. Things newly created at the intermediary, the first-leg destination, have no origin in the source, so they are not created back in Safran.
- New objects added at the intermediary: new activities, and new resources, calendars, structures, or profiles, created on the first-leg destination are not created in the source. The round-trip only updates what already exists there. A count of skipped new items is written to the log.
- New links across projects: a dependency link created between activities from different source projects cannot live in a single project and is skipped. New links within one project are written.
- Projects that no longer qualify: a project whose grouping value changed, so the query no longer selects it, or that was deleted in Safran, is skipped for that run and noted in the log.
- Grouping by project group: only enterprise-field grouping is supported today. Bundling several schedules as a project group is planned for a later extension and is not available yet.
Messages you may see in the transfer log
| Message | What it means |
|---|---|
| "Source network <id> no longer matches the grouping filter / no longer exists... not written back." | A project that was part of the original send-out has since been re-classified or deleted, so it was skipped. Change its grouping value back if you intended it to receive the write-back. |
| "<n> activity link(s) were not written back because they connect activities in different source networks." | A link crossing two projects cannot exist inside one project on write-back. Manage those cross-project links in Safran directly if you need them. |
| "<n> object(s) could not be matched to any available source network..." | These objects could not be traced back to a qualifying project and were left out of the write-back. |
| "Round-trip write-back: N source network(s) will be written... skipped ..." | A per-transfer summary of which projects were written and which were skipped, so you can reconcile the run at a glance. |
Known behaviours and things to watch
- Re-classified projects drop out of the write-back and are reported in the log. If a project's grouping value changes so it no longer matches, it simply is not written this run. Always check the transfer log to confirm every project you expected was written.
- The Only Include Specified Mappings prompt appears immediately. The confirmation appears the moment you switch the setting off, not when you press Save. Keeping it on is the recommended setup for a write-back.
- The default is tied to the predecessor. Only Include Specified Mappings is forced on because the agreement runs after a predecessor. If you later change the frequency away from Predecessor, that enforcement no longer applies.
Schedule Exchange - Round-trip write-back for grouped Safran schedules. Feature guide for planners and agreement administrators.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article