A Link Travels To Facebook, The Video Never Does
Nothing leaves the portal when a viewer shares. A share control in the player posts a link to Facebook, and the recording stays where it was published, under the access rule it already had. That is the whole mechanism, and it is worth stating first because the word sharing suggests a copy being handed over. On a portal built on Nexus positioned as the Enterprise Video Platform, what the control does is let somebody who watched a public recording put it in front of the people who already listen to them.
How it connects
Social sharing is a portal setting. An administrator turns it on for a portal, and the share control then appears in the player, delivered as a JavaScript widget, the connection method the catalog names for this record. Where the setting is off, the player carries no share control at all, which is how an internal portal goes without one.
The control acts on content that is already published publicly. Because only public content can be shared, pressing it cannot widen access to anything: a person who follows the link from Facebook sees what any member of the public could already see. Restricted material is simply not shareable, so the real control is the decision made when the item was published rather than anything in the player.
What travels is a link. The video file never leaves the portal, so there is no copy on Facebook to keep track of, and the content's retention and access rules stay where they were set. Turning sharing on is a configuration change to a portal, not a change to who may see what.
What you can do together
Give a viewer one control
Somebody watching a public recording on Nexus posts the link to their own Facebook feed without leaving the player.
Reach the feed you cannot buy your way into
A link passed on by a neighbor lands among family, friends and the local groups they belong to, which is a different audience from the one that visits an institution's own page.
Keep restricted material out of circulation
The control works only on content already published publicly, so nothing internal can travel this way.
Decide per portal whether the control exists
A public portal can carry it while a staff portal does not, because the setting belongs to each portal separately.
A scenario
- SetupThe portal administrator turns on social media sharing for the public portal, and the share control appears in the player for everyone who watches there.
- ThursdayThe digital team publishes the evening curator talk on the new textiles exhibit as public content. A donor briefing recorded the same week is kept restricted.
- Friday, 19:10A visitor watches the talk at home, presses the share control and posts a link to her Facebook feed. The recording itself stays on the museum's portal.
- SaturdayHer friends follow the link and watch the talk at its source. They reach that talk and nothing more, and the donor briefing offers no share control because it was never published publicly.
- The month afterThe museum leaves sharing on for the public portal and off for its staff training portal, since the setting is made per portal.
What stays where
Facebook receives a link
The video file stays in Nexus. Nothing is uploaded to Facebook and no copy of the recording is made there.
The content's own access setting decides
Only content already published publicly can be shared, so a viewer pressing the control cannot widen access to anything restricted. Because the single copy is the one in the portal, whatever that item's access says later is what a person following the link meets.
The portal decides whether the control appears
Sharing is enabled per portal, and turning it off removes the control from the player rather than changing what anyone may watch.
The video sits where the portal sits
Shared SaaS, a dedicated cloud or your own datacenter, and posting a link changes none of that.
Products and solutions
Residents Watch Without Filling In A Registration Form
Ask a resident to create an account before she can watch a council meeting and a fair number of people close the tab instead. Facebook is the account the widest slice of the general public already carries, including the part of it that has no work email and no reason to make a new password. On a public portal built on Nexus positioned as the Enterprise Video Platform, social sign-in puts Facebook on the sign-in page, and the visitor who picks it arrives as a known viewer with nothing issued to her. Facebook keeps the password. Staff sign-in is untouched.
How it connects
Social sign-in is licensed as its own feature and enabled per portal, separate from the corporate SSO app your staff use. Once it is on, Facebook appears as a choice on that portal's sign-in page. The visitor authenticates at Facebook under Facebook's own policy and comes back signed in, so the portal never handles the password and issues nobody an organizational account.
The portal is a service provider and never becomes an identity provider. A Facebook identity sits outside your directory and brings no groups with it, so what a signed-in visitor may see and do comes from the portal's own settings rather than from directory membership. That is the trade for admitting people you do not employ: you gain the audience, and you take on deciding in the portal what that audience may reach.
Facebook is one of the consumer providers social sign-in supports, alongside Google, Microsoft account, LinkedIn, X and Yahoo. Which of them a portal offers is an administrator's decision, and it changes nothing for staff. Facebook sign-in identifies a member of the public rather than a member of staff, and it is not a route into internal content.
What you can do together
No form between a resident and a meeting
People reach a public portal on Nexus with the Facebook account they already have, with nothing to register and no password for your help desk to reset.
Know who is watching
A visitor who signs in is a named viewer rather than anonymous traffic, which is the difference between a view count and an audience.
Meet people on the account they hold
Facebook sits beside the other consumer providers on the same page, so the resident without a Google account is not turned away.
Leave staff access alone
Social sign-in is licensed and enabled separately from the corporate SSO app on Nexus, so nothing about internal sign-in changes when a public portal opens.
A scenario
- Setup, ITThe portal administrator enables Facebook social sign-in on the public portal and sets what a signed-in visitor may open there. The council's staff portal keeps its own SSO app, licensed separately and untouched.
- Tuesday, 21:30The clerk publishes the evening's meeting recording to the public portal.
- Wednesday, 07:40A resident opens the portal, picks Sign in with Facebook and approves the request at Facebook. She is watching the zoning item seconds later, and the council created no account for her.
- Same morningA second resident signs in with Google from the same page. Both arrive as known viewers with what the council set for public visitors, because neither identity carries a group from the council's directory.
- The week afterThe draft budget review stays on the staff portal behind corporate SSO. Facebook sign-in reaches published content and nothing else.
What stays where
Facebook remains the visitor's identity
The account and the password belong to Facebook and to the person. Nexus stands on the other side of that exchange as a service provider, never as an identity provider.
The portal decides what a signed-in visitor may do
A Facebook identity carries no directory groups, so entitlement is set in the portal rather than inherited. Removing someone is portal-side work too, since the account is not the council's to close.
Nothing changes for staff
Corporate SSO is a separate app under a separate license. Social sign-in serves public viewers, not employees.
The deployment decides where this runs
The portal sits in shared SaaS, in a dedicated cloud, or in the council's own datacenter.
Products and solutions
Next step
See it on your own Facebook instance. We will show the connection made, the data moving and the output, then size it for your deployment.
Request a demonstration or write to sales@vidizmo.ai
sales@vidizmo.ai · vidizmo.ai/integrations/catalog/facebook