Part 3 · Projects, time and knowledge
Federation
Link your Symbifox to a partner's so that tasks, deliverables, meeting agendas and process maps cross over, and whatever moves on their side comes back to yours.
The Fédération (Federation) application links two Symbifox instances that trust each other. An object shared on one side appears on the other, and whatever moves comes back: the state of a task, the read receipt on a deliverable, a topic proposed for a meeting agenda. It is for organizations working with a partner, a subcontractor, a general contractor or a client who also runs Symbifox. Nobody has an account to open anywhere, and no password changes hands.
Overview#
A peer is the other instance. You have as many as you have linked partners. Each peer record carries its address, the state of the link, the person who will be assigned incoming objects, and the size ceiling you accept for attachments.
The link is born of a pairing: one instance issues a single-use code, the other accepts it. A shared secret is derived from both halves, so neither instance picks it alone, and it signs every message from then on.
A federated link ties an object of yours to its mirror at the peer. The original stays yours; the mirror is a living copy that updates and can answer. Nothing is ever deleted: withdrawing a share archives the mirror.
Five kinds of object cross over, each brought by its own module:
- tasks, with their state, their due day, their messages and their attachments;
- delivered documents, with their title, version, date and files;
- meeting agendas, read-only, with the option to propose a topic;
- process maps, with their full drawing and their successive versions;
- the conversation, as one discussion channel per shared object.
What never crosses, under any circumstance: your internal notes, your hours and timesheets, a meeting transcript, your credentials, and any message whose text begins with a padlock.
The list of links gathers everything that has a twin at a partner's, whatever the kind of object.
Configuration#
Pairing is for administrators only. From Fédération > Pairs, create the partner record, then Générer une invitation (generate an invitation). The peer needs two things: your instance's address and the code, valid for forty-eight hours and usable once. You pass them along however you like, or you fill in an email address and let the record send them, in which case it keeps a trace of the recipient.
At the partner's end, Fédération > Accepter une invitation asks for your address, the code, and who should be assigned incoming objects. Both instances are then active, and Tester la connexion confirms it.
Three settings deserve a decision, on the peer record:
- Who is assigned incoming objects. Mirrors arrive in a closed project, visible to its followers only, under that person's name.
- What this peer may send you. By default, everything your instance can receive. You may instead tick a precise list: a partner you only want tasks from will not be allowed to drop deliverables on you. The refusal happens before your instance looks up the object in question, so it reveals nothing about what exists on your side.
- The attachment ceiling. Above it, a file stays with the sender, and the mirror says so rather than pretending otherwise.
Getting started#
Share a first task. On the project, name the peer under Pairs de fédération: without that, no task in the project offers federation, and the field does not even appear. Then open a task and fill in Fédéré avec. A note on the message thread sums up what leaves and what stays.
The mirror appears at the partner's on the next pass of the outbox, within two minutes. They see it in a project named after you, with three columns: to do, waiting on you, done.
When they move their task to Terminé (done), it returns to you En cours (in progress) rather than closing: their part is finished, the ball is in your court. That is the state flip, and it is what keeps a federated task from getting lost.
Common tasks#
Deliver a document. From Fédération > Livrables, create the delivery: a title, a version, a date, a plain-text summary and the files. Fill in the recipient, the contact the delivery is addressed to: they determine which peers may receive it, and with no recipient no peer is offered. The read receipt comes back with the name of whoever read it and the date.
Publish a new version. Change the version and replace the files. At the partner's, the new one replaces the old, files included, and the previous version's receipt drops on both sides: a receipt is about content, not about a title.
Share a meeting agenda. On an agenda whose project names a peer, fill in Fédéré avec. The partner reads it on their side: title, date, place, duration, objectives, context and published topics. They cannot rewrite it, and a banner tells them so. What they can do is Proposer un sujet (propose a topic): it arrives on your side marked as proposed by a recipient, for review, and enters neither the printed document nor the email until you accept it.
Share a process map. Fill in Fédéré avec on the map. The partner receives a real process map, with its levels, lanes, nodes and flows: they can draw it as a PDF and open its step pages. It carries your name in parentheses, to tell it apart from theirs. After reworking the drawing, use Renvoyer le tracé au pair (send the drawing again): levels are not among the watched fields, because a map is reworked through its nodes far more often than through its title.
Open a discussion channel. From Fédération > Liens, the Ouvrir le canal button creates a channel for that object. What is written there is posted to the object's message thread, from which it travels to the partner; what comes from them reappears there. The channel is the window, the message thread stays the record. Expect two to four minutes per round trip: this is not instant messaging.
Withdraw a share. Clear Fédéré avec. The mirror is archived at the partner's, a note tells them, and nothing is deleted. Setting the peer again reactivates the mirror and sends it the complete card.
The menus, one by one#
Fédération > Objets fédérés lists the tasks that have a mirror, with the peer and the direction of the share.
Fédération > Livrables lists deliveries in both directions. Filters separate what you delivered from what you received, and isolate what has no receipt yet.
Fédération > Pairs is each partner's record: the state of the link, the last contact, what they say they can receive, what you allow them to send you, the person their objects are assigned to, and the table of matched people. Administrators only.
Fédération > Accepter une invitation opens the pairing window on the invited side. Administrators only.
Fédération > Liens lists every link, whatever the kind of object, with its model and its peer. This is where an object's discussion channel is opened. Administrators only.
Fédération > Boîte de sortie shows each send, its state and, where applicable, the last error. Administrators only.
Reference#
The table of matched people. A received message is written under the name of someone on your side only if that table says a given address at the peer corresponds to a given contact of yours. Failing that, it is written under the peer organization's name, with the announced name as a prefix. A partner therefore cannot write under one of your employees' names by presenting their address.
The exclusion marker. A message or a note whose text begins with a padlock, or with the word private in brackets, stays with its author. The marker applies from the message thread as much as from the channel.
Announced kinds. Each instance tells the other what it can receive. A kind whose module is not installed at the partner's is refused rather than guessed at. A partner running an earlier version announces nothing, and is then treated as accepting everything: we do not forbid what we cannot see.
Roles. Only an administrator pairs, suspends or reactivates a peer, and sets what it may send you. A project manager shares and withdraws objects. A user reads the federated objects in their scope, like any other.
Modules that extend this application#
Understanding#
Why the object goes to them rather than them coming to you. Symbifox already knows how to open a portal to a partner, and to share a project with editing rights. Those doors work, and they stay lightly used: people work in the tool they open in the morning, not in someone else's. Federation reverses the direction and puts the object where the partner already is.
Why the message thread stays the record. The channel gives the shape of a chat, livelier for back-and-forth. But an object has to keep a single history, readable a year from now by someone who was not there. So the channel writes into the message thread, never beside it.
Why a delivered document rather than a shared object. A report, a policy, a procedure, an exported schedule: these are things you hand over, not things you draft together. Nobody drafts a privacy policy jointly with their client. The delivered document therefore says what it is: a dated version, handed over, that you want to know has been read.
Why the recipient frames the delivery. With a single partner, the question does not arise. With five, a list showing all five makes delivery to the wrong one possible, which is not a typo but a confidentiality incident. The recipient makes the wrong partner impossible rather than improbable.
Troubleshooting#
The mirror does not appear at the partner's. Look at the outbox. A pending send goes out on the next pass, within two minutes. A failed send shows the peer's last answer: an unreachable address, a link it does not know, or a refusal. A send is retried on a growing delay for fourteen days, then abandoned.
The partner refuses a kind. Their own record may limit what you are allowed to send them, or the matching module may not be installed on their side. The kinds they say they can receive are visible on their record, on your side.
The Fédéré avec field does not appear. On a task or an agenda, the project must name a peer. On a deliverable, a recipient is required. On a process map, a client or a project that names a peer.
A received agenda refuses to be edited. That is intended: a mirror is read. To add something to it, use Proposer un sujet, and the sender decides whether to put it on the agenda.
A delivery has nothing left to replay. An abandoned send keeps its trace but not its content beyond a week: the files of something that never left have no business living forever in a queue. Share the object again.
See also#
- Projet for tasks, projects and their waiting states.
- Rencontres for agendas, meeting reports and the client portal.
- Process maps to draw, validate and version a map.
- Base de connaissances for versioned documents and their distributions.
- Discussion for channels and internal messaging.