What's new – Settings

Deleting staff now requires the matching permission (#3411)

The delete button in staff settings used to be visible to anyone who could open the page, even without the "delete staff" permission - a click used to end in a server rejection only. The button now only appears for roles that hold that permission.

The role editor dialog now closes with Escape and is announced as a dialog (#3419)

Blue text in dark mode is now properly legible (#2945)

in dark mode, blue pieces of text - ticket numbers, linked names, active tabs, markers in tables - used a blue that was too dark on the lighter surfaces, cards and table rows. Measured, it reached only 4.4:1 of contrast there; WCAG 2 AA asks 4.5:1 for normal text. On the very dark page background it was barely noticeable, on every raised surface it was - and that is where most of the text sits. Those places now use the lighter blue and reach at least 6.1:1. Hovering still brightens the colour visibly, so the difference between resting and touched is preserved. Icons, borders and the large figures on the KPI cards keep their blue: a different threshold applies to them, and they already meet it. Nothing changes in light mode.

A custom role's rank is now saved

When creating or editing a role under Settings → Staff & roles, the rank set with the slider used to be discarded - the role kept the internal default of 0 and therefore always sorted to the bottom of any rank-ordered list, regardless of what was chosen. Reopening the role also showed the default of 50 again, with no indication that the actual value had never been saved. The rank is now persisted and shown correctly the next time the role is opened, and the role list sorts custom roles into their real place among the system roles.

Permission changes take effect again in every company

Roles, permissions and account changes are carried across in the background into the store that sign-in reads permissions from. For a single company that transfer could come to a permanent halt - permissions there stayed at the state of the day it stopped: a revoked permission kept working, a newly granted one did not apply. The trigger was an account whose e-mail address was still held by a deleted account; the transfer now frees the address before it writes, and retries individual conflicts instead of stopping the whole company. If one account still cannot be carried across, only that account is affected: every other account, role and permission of the company keeps being transferred, and the outstanding account is reported by name. On top of that, each pass now gives up after ten minutes per company rather than waiting indefinitely. Nothing to do on your side - the transfer catches up on its own.

Back to account selection on a company's sign-in page

Anyone who landed on the wrong sign-in page - a mistyped account name, an old bookmark, or a forwarded link - used to have to rewrite the address bar by hand to get back to the general account selection. Every company's sign-in page now shows a "Back to account selection" link right under the title. The link does not appear on the general address itself.

Dropdowns in the settings area are now read out by name (#2859)

Affected were the activity log with its area and method, custom dashboards with the report picker, the data explorer with field, operator, aggregation and sort field, the data warehouse with status and source type, report scheduling, plus the unit and currency fields of custom attributes and the language pickers in the translation view. Anyone using them with a screen reader heard nothing but "combo box" there - with no hint of what was being selected. All of them now carry a spoken name in German and English. Nothing changes visually. Activity log · Data explorer ·

The language picker is now an ordinary select field (#2658)

The language switcher in the user menu used to open a full-height side panel with a search box, flags and a check mark. That shape dates from the time the list held some 40 entries; what is offered today is exactly two, German and English. In place of the side panel there is now the same plain select field that the roadmap portal and the "My Profile" page already use. What changes for you is mainly that the control behaves the same everywhere and works reliably with the keyboard: you reach the field with the Tab key, typing the first letter jumps to the matching entry, and the input focus stays on the field afterwards. On a phone, the familiar picker of your device opens. The flags are gone on purpose: a flag stands for a country, not for a language, and screen readers announce it as a country name. Languages are now consistently named in their own language ("Deutsch", "English"), and the field has a fixed caption that a screen reader can announce. Which languages you can choose from does not change.

The product bar and the quick search explain an empty product list (#2635)

Signing in with an account that has no permissions recorded left the slim product bar on the left edge and the product list of the quick search simply blank - without a word about why. That silent emptiness is what a customer reported in August as "the navigation is gone", because a blank screen offers only one reading: the application must be broken. Both surfaces now say why nothing is there. The quick search carries the notice text, the product bar a marker that opens the quick search with the same text. The notice tells three causes apart and names them: no permissions are recorded (either nothing has been granted yet, or the permission service is unreachable - the two cannot be told apart from the outside), permissions that open no product area, or no product enabled for the company yet. No product the session may not enter becomes visible through this, and an account with permissions sees exactly its products and no notice, unchanged.

You now switch your areas on and off yourself

An area is a menu entry - a sub-page you see in the sidebar. Under "Settings → Areas" there is now a list of every area available to you, with a switch for each. Until now only the platform operator could set this for you. Whatever you switch off disappears from the menu and stops answering over the interface as well - an employee with the matching permission no longer sees the menu entry and cannot get in through the address bar either. Roles and permissions stay untouched: switch the area back on later and everyone holds exactly the rights they held before; nothing is deleted. While an area is off, its permissions do not appear in permission management - which keeps that list short and matched to what you actually use. Areas still being tested do not appear in your list at all; they are not "off", they are simply not yet intended for you. Some areas deliberately arrive with the starting value "off" and then carry the note "Default: off" - you can switch them on at any time. If you decided yourself and want to undo it, "Reset to default" takes you back to the state the area shipped with. Search and filters live in the address, so a view can be handed on as a link.

New employees without a role now really do wait for approval

Someone who had been invited, had set their password and had not yet been given a single role still ended up inside the admin area - where they saw nothing, because they held no permissions. The "Approval pending" page that exists to explain exactly this state was reachable, but nothing ever led there. From now on these people are taken straight to it, on every sign-in path: password, two-factor confirmation and passkey. As soon as you assign a role under Settings → Staff & access, the admin area opens on their next visit. Accounts with the superadmin and owner roles are exempt: they get in as before, even without an explicitly assigned role.

Newly onboarded staff land on "Approval pending" again (#2833)

Anyone who had been created as a staff member but had not yet been given a role was nevertheless let through into the console. What awaited them there was an interface without a single permission: pages that would not open, lists that stayed empty, and no indication that a grant was simply still missing. It looked like a fault, but it was the open step of assigning rights. The check now works again: if the role assignment is missing, every sign-in route - password, second-factor confirmation and passkey alike - leads straight to the Approval pending page, which names the situation and points to the responsible administration. The redirect is decided by the server rather than by the interface, so that all sign-in routes get the same answer. Nobody is locked out by this: existing accounts with an assigned role carry on unchanged, and the operator account with full access still reaches the console even in a tenant where no roles have been handed out yet.

Sanctions screening, regional profiles and data subject requests work again (#2863)

Four legally relevant functions were fully built and reachable from the interface - and still answered every call with a server error, because the storage behind them had never been created in the database. Affected were sanctions screening together with its screening log, the activation of a regional profile under Legal & Compliance, and the data subject requests under GDPR and CCPA that your customers raise in the shop and that you handle in the admin area. All four now store and read as intended; existing tenants get the storage automatically on the next update. On top of that, the GDPR Art. 20 data export now really includes the consent history and the product reviews a customer has written - both sections always came back empty before, which from the outside looked like "nothing on file". If a section of the export cannot be produced, the export now reports that as an error instead of passing off an incomplete archive as a complete one.

The language picker now shows finished translations only (#2667)

The language switcher in the header and the "Language" field under "My Profile" used to offer some 40 languages, of which only German and English are fully translated. Picking any of the others produced no translation but a largely English interface - a choice that could not keep its promise. What is offered now is exactly the set of languages whose texts are fully maintained, currently German and English. As soon as another language is finished it appears in the list by itself; nobody has to register it anywhere. If you had one of the removed languages set before, your interface now continues in German, with no error and no loss of data. Date, number and currency formats and the time zones are unaffected: they still follow your region, independently of the display language.

An empty navigation is no longer possible (#2633)

Until now the left-hand navigation hid every entry without a matching permission - and two central entries, Dashboard and My profile, were nowhere recorded as freely accessible. For an account without special rights that left no menu entry at all, and it did not look like a missing grant but like a broken application. Both entries are now explicitly listed as self-service and are visible to every signed-in account. On top of that, a note appears at the foot of the navigation as soon as no permissions are recorded for your account: it names the two possible causes - access not granted yet, or the permission service currently unreachable - and makes clear that the application itself is working normally. My profile and Sign out are always reachable in that situation. And a saved personal ordering can no longer swallow a menu entry in silence: if it points at a group that no longer exists, the entry stays where it was.

The left-hand navigation can be shown again on a desktop machine (#2617)

If you had collapsed the left navigation with the small arrow in its header, there was no way back to it on a desktop machine: the menu button that offers the way back exists on narrow screens only, and the slim product bar on the left edge carries product names such as "HR" or "Shop" - it does not announce the way back. That is why the navigation was there on a phone but seemed to be gone on the PC. The product bar now carries a dedicated Show navigation button for as long as the bar is collapsed. On top of that, a saved personal navigation layout can no longer empty the bar completely: if your own arrangement hides every group, the standard navigation reappears with exactly the entries you are entitled to.

A takeover no longer ends on the locked area, and page titles are readable again (#2467)

When a SELLERLOGIC colleague was working on your behalf and opened an area of the platform console - via the browser's back button or a reload, for example - the notice "Product not released yet. Contact your account manager." appeared. For a running takeover that was factually wrong, and it was a dead end on top. Such addresses now take you straight back to your start page. On top of that, the header of some console pages showed the raw address fragment instead of a translated title (a lower-case "tenants", for instance); all page titles are translated again.

A sign-in is now valid for at most seven days

Until now a running session silently extended itself by another seven days with every use. Anyone who opened the console at least weekly therefore stayed signed in indefinitely, without ever entering a password or using a passkey again - 19 days in a row in one measured case. From now on a fixed upper limit applies: seven days after your last real sign-in the console takes you back to the sign-in page once, regardless of how active you were. The deadline starts again with the new sign-in. The reason is the protection of your account: a session credential that had been stolen once never expired on its own as long as it was being used. Nothing changes for you in day-to-day use apart from this recurring sign-in - save longer entries as you go if you keep the console open across several days. Sign-in in the storefront for your own customers is not affected.

An account lock now applies on every way into the platform console

When an operator account locked itself out after several failed attempts, that used to block only the password sign-in. Switching over from an area the same person was already signed in to still landed in the console - that path checked only whether the account was still active, not whether it was currently locked. The same was true for the second-factor prompt during the switch. Both paths now check the lock exactly as the password sign-in and the passkey sign-in do; the message is the same everywhere and states in how many minutes you can try again. Nothing changes for your company area - it was never affected by a console lock and still is not.

Cookie-consent receipts are now stored encrypted (#1603)

When a visitor makes a choice in the cookie notice, your shop keeps a receipt of that decision - including the visitor's IP address and browser identification, because without them the consent could not be evidenced. Both were previously stored in the clear. From now on they are stored encrypted, using the same mechanism the system already applies to other personal data fields. Existing receipts are carried over automatically in the background; there is nothing for you to do. Nothing changes in the display, the handling or the analytics, and the receipts remain fully usable as evidence.

Google connections can now be reviewed in one place and revoked in one go (#1255)

SCS keeps Google credentials in four places spread across three areas - the appointment module's service account for syncing your staff list, the HR calendar connection, your employees' personal calendar connections, and the marketing link to Google Ads or Search Console. Until now each area only had its own disconnect button. Revoking access in one area silently left a still valid Google credential behind somewhere else. Two new endpoints close that gap: a disclosure that lists all four places together with how many credentials each currently holds - so a data subject or deletion request no longer requires knowing which area might hold something - and a full revocation that clears all four in a single call. The full revocation asks for an explicit confirmation, because it disconnects the tenant from every Google service and cannot be undone. The existing per-area disconnect buttons are unchanged - disconnecting only the HR calendar does not cost you the marketing integration. A user interface for the full revocation will follow; today both calls are reachable through the API.

Permissions of the "Managing director" role that were displayed but did not take effect (#2150)

During a system change on 22 Aug 2026, 26 permissions of this role were stored in an outdated notation for a few hours. Nothing about this was visible - the permission matrix showed the role fully equipped, yet for 20 of those permissions the system still denied access, because it no longer recognises the old notation. Among the areas affected were settings, order and product editing, and background jobs. A background reconciliation now lifts these entries onto the current notation automatically; there is nothing for you to do, and no permission is lost in the process. Roles you created yourself are never touched, even if they carry the same name.

Signing in no longer ends in a dead end, and a reload keeps you signed in (#2467)

Three things that occurred together are fixed. First, signing in could land on an area that is not released for your own company at all, showing "Product not released yet". The redirect now decides by the session that is actually active and only ever leads somewhere the account may go. Second, on a locked area the menu disappeared, so the only way out was the "Back to dashboard" button - no matter whether you arrived via the sign-in, a bookmark or a shared link. The product bar and the menu now always stay in place; the lock itself is unchanged. Third, a session in which a SELLERLOGIC colleague works on your behalf did not survive a reload: every reload signed you out. That is fixed too.

The help link in the setup assistant opens a new tab

The help block at the end of the assistant is there for when you are stuck - so it is usually clicked in the middle of filling something in. Until now it replaced the assistant in the same window, and whatever you had already entered under Confirm company details without saving was gone afterwards. The link now opens in a new browser tab: the window with the assistant stays exactly as it was, entries included. The link also names the target page instead of describing it by category.

The manual link in the setup assistant now opens in a new tab

At the bottom of the setup

"Disconnect" on a connected app now asks before the connection is gone

In the app configuration, under the Sign in tab, a Disconnect button sat next to the connected address and fired on the first click. That severed the connection and revoked the stored access token - the app stopped working until somebody signed in with the provider again, and this screen offered no way back. A confirmation now appears first; it names the affected address and states that this cannot be undone. Only your confirmation disconnects. Connecting is unchanged - signing in with the provider stays a single click, because it can be undone at any time.

An overdue process now becomes additionally visible one level up

If a process stays undecided for longer than its deadline allows, it also appears in the worklist of the responsible person's supervisor. It does not move - the responsible person keeps it, otherwise they would lose sight of it and the responsibility would be blurred. This happens exactly once and one level far: the process does not climb the whole management chain day by day. If no next level is recorded for the responsible person, the process stays where it is and the gap in the personnel data is reported to your administrators - it does not vanish silently.

Analytics now asks before anything disappears for good (#1916)

Under Analytics → Data warehouse the bin icons removed an ETL pipeline, a materialised view, a BI connection or a retention rule on the first click - no question asked and no way back. The same was true for a tile under Analytics → Dashboards and for a schedule under Analytics → Report schedules. All seven of these deletions now show a confirmation that names the affected record. Creating, editing and saving are unchanged - they still happen without a confirmation, because they can be taken back.

Open worklist entries now close even when a notification failed to fire technically (#2287)

An entry in your worklist - an approval, for example - disappears once the underlying matter has been decided. Until now that depended solely on the moment of the decision; if the notification about it technically failed to fire, the entry stayed open even though there was nothing left to do. A recurring background reconciliation now also checks open entries against their actual state and closes them after the fact whenever the direct closing once failed to happen. You will only notice this if an entry would otherwise have been left stuck - it now disappears on its own, at the latest with the next reconciliation.

Settled processes can now be read up in the archive

When a process disappears from your worklist it is not gone - under Settings → Notifications → Process archive you will find it again, with when it was raised, when it was settled and the path by which it was closed: by the decision on the process itself, or by the periodic reconciliation that closes a forgotten entry after the fact. If a process reached you through escalation, the row says so too. Search, process kind and page number live in the address bar, so a view can be bookmarked as a link. You only ever see your own archive; that is enforced on the server, not merely hidden. Nothing is deleted - how long entries are kept is still an open decision. What the archive deliberately does not claim: who decided. That is recorded on the process itself, and a guessed name would be worse than none.

The bell is now a worklist, not a chronicle

alongside the existing messages (release, maintenance, security) it now holds processes - things waiting for an action from you. A process appears for exactly the person meant to decide it, shows how long it has been waiting, a deadline marker ("on track", "due soon", "overdue") and what to do, and disappears on its own once the matter is settled - whoever settled it. The number on the bell therefore means "this much is waiting on me" instead of "this much has happened". The deadline marker never relies on colour alone: each state also carries its own icon and its own wording. Processes deliberately cannot be switched off - whoever could switch off their worklist would leave approvals sitting for weeks without anyone noticing. Absence requests come first; further process kinds follow.

The help navigation now behaves the same inside the product and on the public site - and is usable on a phone again

The two versions used to build their menus separately, which produced four differences on identical content: pages within an area were sorted by your browser's language setting rather than the language of the content, the What's new entries were missing from the in-product rail entirely, and clicking the area you were already in took you back to the start page instead of to that area's overview. Both menus are now derived from one shared source, so those differences are gone. On narrow screens the article now comes first: in the CRM area, 68 expanded entries sat above the text, and measured at 390 pixels wide the article did not start until 2527 pixels down - a good three screens of scrolling. The navigation now sits behind the Navigation button and slides in over the text; Escape closes it. There is also a new filter field above the list: looking for "Calls" is three keystrokes rather than a scroll. The Platform area remains in-product only and visible to operator accounts only - it is not merely hidden from the public site, it is not present there at all.

You can now unsubscribe from emails for individual process kinds

Under Settings → Notifications → Process notifications you decide per process kind whether you want an email about it. The setting applies to you only. Your worklist is not affected - the bell entry deliberately cannot be unsubscribed from, because anyone who could switch off their worklist would leave approvals sitting for weeks without anybody noticing. Process kinds whose email is compulsory, or that send no email at all, are shown with a greyed-out switch rather than hidden - so you can tell they exist.

"Legal & Compliance" now only shows up for someone who can actually open it

The menu entry under Settings was visible to practically every role, but only actually led to content for the Administrator and Super-Administrator - everyone else saw a dead entry. That happened because visibility was tied to a different permission than the page itself. Both now match: if you cannot open the page, you no longer see the menu entry either.

A cancelled invitation no longer leaves a half-created employee

Previously, sending an invitation created the account, the personnel file, the employee record and the invitation link one after another. If anything went wrong along the way, whatever had already been written stayed behind - and a second attempt with the same address did not simply pick up where it left off, it failed with an internal error. This also affected the harmless case of inviting an address a second time while the first invitation was still pending: instead of the message "A user with this email already exists", you got an error. Both are fixed. The four records are now created in one go - all or nothing - and a second attempt always leads to a complete result. Older leftovers from before this fix are detected and picked up automatically.

A permission change now takes effect on its own, with nobody having to step in

After you removed or granted a permission for a role under Staff & roles, sign-in could keep deciding on the old state for a long time - a revoked permission stayed effective, a granted one did not take hold. The cause was a sync between two data stores that a person had to trigger by hand; if it was not triggered, the old state simply stayed, and there was nowhere you could have seen that. That sync now runs by itself and repeatedly. Nothing changes for you in day-to-day use - a permission change takes hold from the next sign-in, or as soon as the current access token is renewed, with nothing further to do. Newly created workspaces are covered from the start.

Five areas now demand a permission instead of a mere login

Review moderation, product streams, custom product fields, the timezone together with the business hours, and the entire marketplace administration checked no permission at all on the server - being logged in was enough. Anyone who had taken the matching permission away from a role under Staff & Roles saw a boundary in the interface that the server did not draw: the call went through anyway. From now on: approving, rejecting, answering or deleting a review requires Moderate reviews; product streams and custom product fields require Edit products; timezone and business hours require Edit settings; the marketplace administration (configuration, contracts, vendors, listings, commissions, payouts) requires Edit marketplace. The shipped roles lose nothing - super-administrator, administrator and editor already carry all four permissions; the viewer was never meant to edit these areas and now cannot. If a role you created yourself is affected, grant it the named permission once.

Inviting, editing and removing a team member can now be granted separately - and the subscription is protected again

Staff & Roles already had separate checkboxes for "Invite", "Edit" and "Remove" in the Team area, plus "Read billing" - they just had no effect: a role without those checkboxes still got through, and a role with exactly those checkboxes (and nothing else) did not. Both directions are fixed now. This mostly shows up on a custom-built role that carries only one of these permissions - a "Front desk" role that is only allowed to invite now actually works that narrowly. The shipped Administrator, Editor and Viewer roles are unchanged, since they already carried the matching checkboxes. The "Read billing" permission for the subscription overview had never been checked at all - any signed-in staff member could read it regardless of role; that is now restricted to the super-administrator, the same circle that could already change the subscription.

Roles appear under their name again instead of their identifier

Every role picker - Roles in the employee record, the invitation dialog, the staff settings and Staff & Roles - had been showing the technical identifiers "superadmin", "admin", "editor" and "viewer". The names were stored all along; the server simply did not send them. You now read Super Administrator, Administrator, Editor and Viewer again. Second, those four names now follow your display language: in German they read "Super-Administrator", "Administrator", "Redakteur" and "Betrachter". A role you created yourself keeps the name you gave it - that one is never translated, and a role with no name at all still shows its identifier rather than an empty line. The same change puts the role lists back in their intended order: by rank, from the super administrator downwards.

Salaries, bank accounts and the audit trail are now reserved for the super-administrator

Since the day before yesterday the shipped Administrator role reached the sensitive areas - salary and compensation data, salary bands, bank accounts, accounting, cash flow, invoices, revenue figures, billing, privacy requests and the audit trail. The last one decided it: whoever can read and manage the audit trail manages the record of their own actions. Those 30 permissions now sit with the super-administrator alone; they have been taken off the administrator role - in existing workspaces too. The actions that belong to those areas went with them, not just the read permissions: posting and exporting in accounting, bank import and reconciliation, sending invoices and approving compensation. Everything else stays with the administrator - products, orders, CRM, settings, HR outside compensation, approving absences and expenses, refunds, invitations and resetting access. Viewer, editor and super-administrator are unchanged. If somebody below the super-administrator needs these areas, create your own role under Staff & Roles and grant the permissions deliberately; roles you created yourself are untouched by this change, even when they are called "Administrator".

The "Read employees" and "Edit employees" permissions now actually do something

Under Staff & Roles you could already scope a role to exactly the "Employees" area without also granting the far broader "Read HR"/"Manage HR" permissions - but the server never checked either of the two narrower permissions, so any role built that way was refused on the employee list and on every single employee record. That is fixed: the employee list, the detail view, creating and editing an employee, and terminating or reactivating one all now accept both narrower permissions alongside the existing ones. The shipped roles are unaffected - super-administrator, administrator and editor already carry both, the viewer carries the read permission. Contracts and the compensation history deliberately stay on "Manage HR" - that is a separate, stricter tier.

The invite dialog under "Staff & roles" is a real form now

You enter an email address there, pick a role and send the invitation off. Until now the send button was just a button next to the fields - the Enter key did nothing, and the address you typed was not checked by the field. Both now behave the way a form is expected to: Enter submits, and an incomplete address is caught in the field itself. This path deliberately gets no extra confirmation - you filled in the fields and deliberately sent them off, and that IS the confirmation. Asking again where it protects nothing only teaches people to click every question away.

The password-reset link no longer carries its secret visibly in the address

The link in the "forgot password" email is worth as much as your password itself - whoever holds it sets a new one. Until now the secret sat in the query part of the address (behind the question mark) and was written down in places nobody treats as a secret store: the access logs of the servers along the way, and the browser history. It now sits behind a hash sign - a part of an address that browsers never send to a server at all. On top of that, the secret disappears from the address bar once the page has loaded. Nothing changes in how you work, and links already sent stay valid and keep working unchanged until their hour is up. Applies to the admin area and to shop customer accounts alike.

A lock or a deactivation now takes effect in the middle of two-factor sign-in as well

Entering your password and your second factor in two steps leaves a five-minute window in between. If an account was deactivated inside exactly that window - the "a colleague leaves the company today" case - or if the lockout after several failed attempts kicked in during that time, signing in with the code from the authenticator app or with a recovery code still went through. The account state is now re-checked immediately before the session is issued. What you see: the page now names the real reason - a deactivated account, or a temporary lock together with the number of minutes after which you can try again - instead of blaming the code as it did before. The wording is the same one the password sign-in already uses. And your recovery codes stay untouched: a rejected attempt no longer uses one up, which is what happened before - the codes work only once, and an attempt that could never have succeeded cost you one of them. Signing in with a passkey already checked the account state.

A new workspace now ships with four working roles

Until now every newly created workspace opened Staff & Roles with no role at all - the list was empty, and inviting somebody as "administrator", "editor" or "viewer" in truth handed over no permission whatsoever: all three were identical in effect, namely ineffective. It went unnoticed for a long time because the owner of a workspace bypasses every permission check anyway. Four roles are now in place: Super-Administrator, Administrator, Editor and Viewer. The cut follows one simple rule - reading sits below writing, writing below managing. Sensitive areas are excepted and start at administrator: salaries and compensation, salary bands, bank accounts, accounting, cash flow, invoices, revenue figures, billing, the audit trail and privacy requests. A viewer sees none of it, not even read-only. Approvals, refunds, payment captures and resetting somebody's access sit with the administrator as well. Existing workspaces lose nothing - the four roles are added, existing roles and their permissions stay untouched, and a role you created yourself that happens to carry one of the four names is left alone. No SELLERLOGIC operator-plane permission is part of any of the four roles.

An invitation no longer fails because the person already works somewhere else on the platform

Inviting an address that already had a SELLERLOGIC account produced "a user with the e-mail ... already exists. Invitation failed" - even though nobody in your workspace carried that address. A person has exactly one account and can be a member of several workspaces; the invitation nevertheless created a second account every time and ran straight into the uniqueness rule. Now the existing account is linked to your workspace instead. Password, name and the roles in the other workspace stay untouched - your workspace cannot change any of them, and the role the person gets with you is entirely your decision. Second, a failed attempt no longer blocks the address for good: until now it left half a record behind, and every further attempt reported "already exists" against exactly that leftover. A second attempt now recognises it and takes it over - simply invite the person again; nothing has to be cleaned up or deleted by hand. The "already exists" message still appears when the address really does belong to a staff member in your workspace, or when an invitation is still open there.

The last few spots: "workspace" now stands wherever it used to say "tenant"

The August 20 sweep had missed six individual places that still carried the internal word - the confirmation prompt in the CRM call log, the profile hint about passkeys, the booking languages in appointment settings, the override hint on absence-approval rules, the SDK keys description, and the branding-source label in the email log. All six now say "workspace"; the operator console still says "tenant" as before.

The sample address now disappears from existing workspaces too

Since 20 August no new workspace carries the invented sample address "Musterstraße 1, 33098 Paderborn" with its invented phone number and invented contact address any more. Anyone whose workspace was created before that could still have it on file - and those are the fields that appear in your imprint and in e-mails to your customers. They are now cleared once, so that nothing stands there that you never entered. What you will notice: under Settings → Company details the address, phone number and contact address are empty, and the setup wizard shows its first step "Confirm company details" as open again - please enter your real details there. What stays untouched: everything you maintained yourself. Clearing only happens where street, postcode and town carry the sample values all three at once; a real address in Paderborn is not affected. A contact address or phone number you had already corrected yourself is kept as well. The shop name is never changed.

Two new permissions in the role dialog: "Send invoices" and "Place a call"

Both actions reach outside the house and could not be separated from the matching edit permission until now - whoever could edit an invoice could also send it, and whoever could set the phone system up could also dial with it. Under Staff & Roles the two now appear as permissions of their own in the Invoices and Telephony groups. Existing roles lose nothing - every role holding the respective edit permission received the new one automatically. What is new is that you can take sending, or dialling, away on its own.

A new workspace no longer starts with somebody else's demo address

a workspace's settings - shop name, contact address, phone and postal address - are created in two places: when the workspace is created, and when the settings page is opened for the first time. The second place used to insert demo data: a demo shop name, an address in Paderborn and an invented phone number. Which of the two you got depended on which path touched the workspace first - and the contact address is exactly the field that appears in the imprint and in mails to your customers. These fields now stay empty until you fill them in; the setup assistant asks for them in its first step. Two effects you may notice: the step "Confirm company data" no longer counts as done while the details are missing - and where demo data used to stand, nothing stands until you enter something. Details you have already maintained are unchanged.

Data explorer: confirmation before a saved query is deleted

Under Analytics → Data explorer, the bin icon on a saved query used to delete it on the first click. A confirmation naming the query now appears first.

Field captions in settings are now linked to their field

In the settings overview and under currencies, metafields, legal & compliance, staff & roles (IAM), reports, accessibility and on the operator console sign-in page, the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name - you heard "edit box" instead of "Currency code, edit box". 43 captions now carry that link. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. Three places sound different, all under staff & roles (IAM): above a role's colour swatches, above a role's permission list and above the action picker of an override rule, the caption does not sit over a single field but over a group of several controls. A screen reader now announces a group with that name.

Field captions in the settings are now linked to their field

Across the analytics pages (custom dashboards, data explorer, data warehouse, report scheduler), the bounce dashboard, the SDK keys and the LLM providers the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name - you heard "edit box" instead of "Subject, edit box". That link is now in place. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. Some places sound different: there the caption does not sit above a single input but above a group of several controls - a dashboard widget's type, data source, date range, colour and position, a scheduled report's frequency, recipients and format, the one-time reveal of an SDK key together with its buttons, and the provider type of an LLM connection. A screen reader now announces a group with that name.

The admin interface no longer asks the browser for a display language

Dates and amounts in the admin interface were produced by helpers whose last fallback was the browser's language setting. With no stored preference - a freshly set-up browser, cleared storage, a private window - the browser decided the format. Anyone using the interface in German on an English-configured machine therefore saw English dates inside a German interface. With no stored preference the application's own default language now applies. An explicitly chosen language works exactly as before.

The help link in the setup assistant leads to the handbook again

the link Help on the setup assistant pointed at an address the knowledge base cannot have, and answered every click with "there is no page on this topic yet". The page was written - it merely sat in the Platform area, which is the operator console and is never delivered into a tenant's knowledge base. The page now lives under Settings, where the assistant itself is found, and the link works. As a side effect the handbook is now also reachable from the help button of the Setup page itself.

The interface now says “workspace” instead of “tenant”

Across settings, the email log, absences, tasks, languages and the signing settings the same thing went by three different names - “tenant”, “Mandant” and “Arbeitsbereich”, and on the Domain settings page all three appeared side by side. The setup wizard has always said “your workspace”; the rest of the customer interface now follows it. The caption above the slug, for instance, reads “Workspace slug” rather than “TENANT SLUG”. The operator console keeps “tenant” as internal vocabulary, and in HR “Arbeitsbereich” still means a department.

The metafield input caption is now linked to its field

The caption of a metafield was not technically linked to the input below it. Clicking it did not put the cursor in the field, and a screen reader announced the field without a name. Because a metafield can consist of several controls depending on its type - value and unit for a measurement, or amount and currency for money - the caption is now announced as a group with that name. Nothing changes visually.

The signing day on a document, the registration day of a tenant and the day axes of the operator lists no longer convert to world time

the visible value of the date signed field on a document, the registration day of a newly created tenant, the reference day of the daily workload in booking, the day axis of the delivery statistics and the date columns of the operator's compliance and revenue lists used to be cut out of world time (UTC). Between midnight and 02:00 German time that was the previous day - so signing at 01:00 put yesterday onto a legally binding document, contradicting the ceremony's own audit trail. All of these now come from the tenant's time zone (Settings > Time zone); on the operator level, where there is no tenant, from the declared zone of the operator console. In addition, three places in booking lost a trick that used a language to obtain a date format - the zone was always chosen correctly there, and the results do not change. Titles of internal AI notes, export file names and the handbook's lastmod values deliberately stay in world time. Nothing is rewritten retroactively.

Analytics moved to the shared controls (technical)

Across the analytics pages - custom dashboards, data explorer, data warehouse and report scheduler - buttons as well as input, select and text fields now come from the interface's shared building blocks instead of per-page code. Look and behaviour stay the same; what becomes consistent is keyboard focus, contrast in dark appearance and the behaviour of disabled fields. Icon-only buttons additionally carry a screen-reader label throughout.

Feedback after saving is visible again

In several areas of the admin, saving, deleting or importing produced no feedback at all - no green confirmation, no red error. Affected areas included absences and absence planning, holiday calendars, cost centres, locations and legal entities, expenses, payroll runs and reports, customer segments, metafields, redirects, email templates and the CRM lifecycle settings. The actions themselves completed correctly; only the message was missing, which was indistinguishable from "nothing happened". The cause was a second notification mechanism running in the background that was never displayed; it has been removed and every area now uses the same one. As a side effect, a technical policy violation that appeared in the browser console on every page load is gone too.

No registration is offered on the company network any more

On the internal address the sign-in card carried "No account yet? Register now" at its foot. The hint led nowhere there: that address is reachable only inside the SELLERLOGIC network, and anyone wanting to register cannot call it up at all. On the public address the hint stays unchanged.

The invitation link no longer reveals the full work e-mail address - and can no longer be probed in bulk

The page on which a newly invited person sets their password used to show first name, last name and the full e-mail address as soon as a valid invitation link was opened. Anyone who got hold of the link - through a forwarded mail or a shared screen, say - read the full work address along with it. The address is now shown shortened only (first and last letter of the part before the @ sign only): enough to reassure you that this is your account, too little to write down. In addition, the invitation path now has its own abuse brake: anyone trying invalid links in series is turned away for 15 minutes after ten failed attempts. Genuine invitations are unaffected - even when many new colleagues open their link at the same time from the same company network, because only rejected links are counted. If the brake does trigger, the page says so explicitly and points out that your invitation link is still valid.

The operator console sign-in now opens light when you arrive from a light surface

The console sign-in always opened dark, even if you had just been working with a light appearance. The cause was not the setting itself but its reach: the chosen appearance is stored per address, and on the company network (admin.scs.sl.local) the choice made on the public address simply is not present - "nothing stored" fell through to the surface's dark default there. Sign-in and registration pages now open light consistently unless you explicitly chose dark; the console sign-in thus follows the same rule as your company sign-in. After signing in your setting applies unchanged.

Unique page titles

Several help pages carried exactly the same name as a page of the same name in another area, which made them impossible to tell apart in search results and listings. Affected in this area: Activity Log (Settings) and Reports (Settings). The page addresses do not change, so saved links and bookmarks keep working.

An incomplete backup now reports itself as failed instead of completed

If an expected table could not be read while a backup was being created, the file was stored anyway and the run was listed as Completed; the problem was only mentioned in the technical log. A file that silently misses something looks like a backup - and you only find out when you restore it, which is the worst possible moment. From now on such a run ends as Failed, names the affected table in plain language and stores no file at all. Normally nothing changes for you; if you see a failed run, please start it again once the stated cause is fixed.

Restoring accounts and passkeys actually works now

When restoring a backup, the restore aborted at the first table containing a list or settings field - in the users-and-permissions area that meant right at the user account (permissions, preferences, recovery codes) and at the passkey. Both the tenant and the platform part were affected. This only came to light when restoring against a real database. Fixed - accounts, roles, permission exceptions and passkeys come back in full.

Sign-in now opens light instead of dark

The sign-in page used to inherit the admin interface's dark default - most noticeable when a visitor arrived from the light homepage and had never chosen a dark appearance themselves. From now on sign-in defaults to light, even when the browser has no stored choice yet, or has "System" stored while the device is set to dark. Anyone who explicitly chose dark - via the switch on the page itself or on one of the other surfaces - still sees dark; that choice continues to apply to registration, sign-in and the admin interface together. Nothing changes for the signed-in admin interface, which stays dark by default.

Signing in on the general address now leads to your own company, not the operator console

Opening https://admin.scs.sellerlogic.com without an account name used to redirect unconditionally to the operator console - a company account could never sign in there in the first place. The page now explains that sign-in happens at your own address, asks for your account name, and shows the resolved address as a link as soon as you type it. The path to the operator console remains available as a separate link for SELLERLOGIC employees. Second, the sign-in form now names the reason for a failure instead of always showing "Login failed": "Service unreachable" and "Workspace not ready yet" appear as their own messages - wrong credentials deliberately stay unspecific.

CRM settings: integration card and lifecycle stage now reliably keyboard-operable

An integration card under Settings → CRM → Integrations already looked focusable but didn't actually respond to Enter or Space - keyboard operability was only apparent, not real. That's fixed. A stage row under Settings → CRM → Lifecycle can now also be reached with the Tab key and selected with Enter or Space.

Staff card now reachable without a mouse

Under Staff & Access, a staff member's card could previously only be opened with a mouse click to edit their details. Fixed: the card can now be reached with the Tab key and opened with Enter or the Space bar.

Backups now include roles, permission exceptions and passkeys

A backup used to carry the user accounts, but not the roles, the role assignments, the individual permission exceptions, the passkeys (password-free sign-in), the password history or the session overview. On restore the accounts were back - but without any permissions and without a registered sign-in method; the backup file looked complete all the same. Fixed: the "Tables" selection now offers the complete users-and-permissions area, the export carries it, and the restore replays it in the correct order - the role first, then its assignments - so a restored staff member has the same roles and the same passkeys as before the backup. If you pick individual tables, the interface warns about missing dependencies as usual (for example "role assignments without roles"). This does not apply retroactively: files created before this change do not contain that information - if you need a dependable backup, please create a new one.

The cookie notice actually appears now - and the decision controls Google in full

The cookie notice was fully built but was never mounted anywhere in the shop. No visitor ever saw it, nobody could consent, and so the analytics feature we offer was simply unusable for your shop. The notice is now mounted and appears on a first visit according to your configuration. Three further changes come with it: First, the decision now controls all four Google signals instead of analytics alone - the Analytics category switches measurement, the Marketing category the three advertising signals. Anyone who consents to analytics only is measured but not evaluated for advertising. Second, every later change takes effect immediately, with no page reload; after the decision a "Cookie settings" button stays permanently in the bottom left, so your visitors can withdraw as easily as they consented. Third, nothing is loaded before consent - as long as nobody has decided, the Google script does not exist in the browser at all. For visitors who had decided about analytics before, their earlier decision continues to apply unchanged; explicitly for analytics only - marketing stays rejected until they select it themselves. Note on the "Default behavior" setting: the "Opt-out" value no longer has any effect. Optional categories are never pre-ticked in the notice, because a pre-ticked box is not valid consent; your shop always behaves like "opt-in".

The "handbook" is now the "Knowledge Base" - and the public version looks like the one in the portal

The collection of all guides is now called the Knowledge Base everywhere - in the portal under Help, in the command palette, in the contextual help panels and in the freely accessible version at docs.scs.sellerlogic.com. That public version now carries the same header as our main site - same logo, same controls, same light and dark appearance, same browser icon - with the search centred in the header, a drop-down covering every area, and the way back to the main site via the logo. Home page, area pages and release notes follow the portal's structure: area tiles with a description and a page count, the three newest updates as cards, and the release notes themselves grouped by month and product. The search behaves the same way too: same weighting, same typo tolerance, same result presentation with the match highlighted, and Enter jumps to the first result. Your addresses and bookmarks stay valid.

Individual permission exceptions for single users now actually take effect

Under "Staff & Roles" you can grant a single user an additional permission or explicitly revoke one, independent of their role. Until now these exceptions were saved and displayed but ignored at sign-in - a revoked permission remained usable, an additionally granted one never arrived. This is fixed: exceptions now take effect no later than the affected user's next sign-in. Exceptions recorded earlier are kept and apply from now on - so please review once whether the stored exceptions still match your current intent.

Permission changes and signing out now take effect immediately, not after up to 15 minutes

When you withdraw a role or permission from a user under "Staff & Roles", change an individual override, or deactivate their account, the old permission set previously remained in force for up to 15 minutes - for as long as the affected user's running session stayed technically valid. This is fixed: the change applies from the affected user's very next action; a deactivated account is signed out immediately. Signing out itself is now complete as well - after "Sign out" the session is ended everywhere, even if the browser window was still open. Users whose access remains valid notice nothing and keep working without interruption.

Recovery codes only count as a second way once you have confirmed you stored them

Since 4 August the platform console has required a second way in before a passkey becomes mandatory - existing recovery codes were enough to satisfy that. There was a gap in it: you get to see the codes in plain text exactly once, after which we only hold them encrypted. Anyone who generated them and closed the window without writing them down ended up with ten rows in our database and still no usable way back into their account - the safeguard was met on paper and not in reality. From now on a set only counts as a second way once you have explicitly confirmed that you stored it outside the system. Existing codes stay valid and there is nothing to catch up on; the confirmation is only requested the next time you generate a set.

The English interface in Settings speaks English

On the page for setting up a Google mailbox and in the CRM connections overview, labels such as "E-Mail-Aliase", "Primär" and "Standard", the loading hint, the note about missing aliases and the buttons for adding and removing a category all stayed in German. They are now maintained in both languages.

A passkey only becomes mandatory once a second way in is secured

Creating a passkey for the platform console used to make it the only way in immediately. If that single passkey was lost or no longer matched the address, the account was locked out - and the page for creating a new passkey sat behind that very prompt. That is exactly what happened on 4 August. From now on, before passkey enforcement takes effect the account must already have either another passkey or valid recovery codes. If neither exists, the system declines the setup with a note asking you to create recovery codes first and keep them outside the system.

An enrolled passkey ends the setup prompt

Anyone who followed the "MFA setup required" prompt and added a passkey was still sent back to the same page after every sign-in - and saw the notice sitting above the list of passkeys they already had. Only an authenticator app counted as set up, not the passkey the prompt itself asked for. Both count now: after your first passkey, the notice and the redirect are gone.

An existing passkey now counts as set up everywhere

Anyone signing in through an address other than the one their passkey was created under was sent back to set up two-factor confirmation - even though one had long been in place. Being told to set up something that already exists is a dead end. From now on a passkey on any of your sign-in addresses means "set up". Instead of the prompt you see a note in your profile telling you which address your passkey applies to and how to add one for the address you are on.

Long option lists now come with a search field

Select fields with many entries - language and time zone under "Profile > Regional settings" above all - used to make you scroll the whole list; for time zones that is around 400 rows. Those fields now open as a list with a search box on top: type "Berlin", "Europe" or even the technical identifier "Europe/Berlin" and the list filters along. Everything stays fully keyboard-operable (arrow keys, Enter, Escape). Also switched over: the business-hours time zone in the service area, the language picker in the API documentation and the test area, and the two font fields under "Design". Short option lists with a few fixed choices are unchanged.

Notifications show up instantly again, including on your public address

New notifications only appeared in the admin area when the list refreshed on its own - depending on the timing, with a noticeable delay. The cause was a missing live connection on the public address {your-slug}.admin.scs.sellerlogic.com; inside the company network it had been working all along. That connection is now set up for both addresses. There is nothing for you to do and nothing gets lost: whenever the live connection is unavailable, notifications keep refreshing on a regular interval as before.

Only the newest password reset link stays valid

Clicking "Forgot password" several times left several valid links in your inbox at once - up to five, each usable for an hour. An older, forwarded or archived e-mail therefore stayed live long after a new one had been requested. Every new request now immediately voids all links sent before it. Only one thing changes for you: always use the e-mail that arrived last. If you open an older link by mistake, you will see a notice that it is no longer valid and can simply request a new one. This applies to the admin area and to customer accounts in the shop alike.

Passkeys from before the changeover are offered again - and when they are not, we say why

A passkey remembers the address it was created under. Since the changeover at the beginning of August, sign-in always asked for the new, shorter address; passkeys from before that did not match and were never even offered by the browser - it looked as if they had vanished. We now record which address each passkey belongs to and ask for exactly that one. And if your passkey belongs to an entirely different address - the company-network one, say - the message now states that explicitly, including the address, instead of failing without comment. Technically a passkey only ever applies to one address; for a second address add another one under "Profile".

Recovery code now offered during platform console confirmation too

When switching into the platform console asks you to confirm with a passkey, that screen now also offers the recovery code field. Until now it appeared only after a full sign-in with e-mail and password - so anyone without a passkey at hand saw no second route at all at that point.

Recovery codes are finally shown, and stay available

Under "Profile", the "Two-Factor Authentication" section only offered "Generate new codes" - and clicking it visibly did nothing. The codes were created but never displayed, and any error stayed silent. That made the second route into your account worthless, because nobody could save it. The codes now appear right after they are created, with a copy button, and the new "Show codes" route brings back every still-valid code at any time. To protect them, both routes ask for your password, and every retrieval is logged.

Recovery codes work without an authenticator app too

Anyone working with a passkey only could create recovery codes but not redeem them when signing in - they were rejected with a message saying no two-factor confirmation was set up. Those are exactly the accounts that need the codes most. A code is now accepted from every account that has codes on file.

Staff tiles, user list and account menu without initials circles

The colored initials circle has been removed from the staff tiles under Settings and from the list under "Users & roles". The account menu in the top right now opens via a neutral user icon instead of the initials - the click target is unchanged.

The platform console no longer throws you out of your own area

Accounts with access to the platform console were pushed to the console's passkey sign-in within seconds of signing in - from any page at all, including the very page where the second factor was meant to be set up. The cause was the console's background queries, which run quietly behind every page. They now rest for as long as the console asks for a passkey sign-in, and only a deliberate click still leads there. Your own area is fully usable again - it never requires a platform passkey in the first place.

Internal storage-key rename completed

After the platform was renamed to SELLERLOGIC Commerce Services, around 30 technical browser storage keys (for session, cart, cookie consent, language and wishlist) were still running under the old name in the background. They have now been switched to the new name, with automatic adoption on first load - you won't notice anything, and nobody loses their session, cart or cookie consent.

Links in our emails point to your public address again

Automated emails - the password reset mail above all - recently carried an internal company address. Anyone clicking it from outside our corporate network reached nothing at all. This affected addresses stored before the rename, as well as every account that had entered nothing of its own under "Domains & URLs". Both are fixed: stored legacy addresses were switched over to your public address once, and an empty field now automatically resolves to https://{your-slug}.admin.scs.sellerlogic.com and https://{your-slug}.scs.sellerlogic.com. A custom address you entered yourself stays exactly as it is.

One consistent height for searchable select fields

Select fields you can type into - country, currency, or the employee picker in absence management, for example - were taller than the buttons and fields next to them. They now follow the same measure as every other control in a toolbar. Handling and function are unchanged.

Passkeys from before the end of July need to be created once more

When our address changed at the end of July 2026, passkeys created before that lost their validity - they are no longer offered to you when signing in. If this affects you, sign in once with your password and a recovery code, then create a new passkey in your profile. That is a one-off. If your recovery codes are missing too, please contact a colleague with administrator rights.

Passkeys now survive a change to your account address

A passkey remembers the address it was created under. Until now that was your full sign-in address including the account name - so whenever an account was renamed or our address changed, every passkey stopped working at once. Newly created passkeys bind to the sign-in address as a whole and therefore stay valid across a rename. Existing passkeys keep working unchanged; you do not need to do anything.

Social sign-in on the storefront fixed

After signing in via a social network (for example Google), the session used to be saved under a key the application never read. This meant customers were silently signed out again after reloading the page. Sign-in now persists as expected.

The new name now also appears in your shop, in e-mails and in the passkey dialog

After the platform was renamed to SELLERLOGIC Commerce Services, the new name had not reached every corner yet. Now updated: your shop's header and footer including the wording in all 43 languages, the footer and subject lines of automatic e-mails, and the name your browser shows when you create a passkey. Nothing changes in substance - your data, settings and addresses stay as they are.

The password reset link no longer sends you to the sign-in page

Following the link from the email took you to the sign-in page and asked you to sign in first - precisely what a forgotten password makes impossible. The link now opens the page for setting a new password directly. The same applies to the other pages that must be reachable without signing in (sign-in, sign-up, invitation/onboarding).

Every product in one place

The quick search (Cmd + K or Ctrl + K) is now also your entry point to every product. With nothing typed it shows your favourites, then every product grouped by topic - Sell, Customers, Operations, Workplace, People, Platform - and finally the entry points into the handbook. Each product appears with its icon, name and one sentence on what it does. You can also open the window with the grid icon at the top of the left icon bar.

Favourites instead of a fixed quick-access list

The previously fixed quick-access list has been replaced by your own favourites. As long as you have not set a favourite, the section is not shown at all. You still set favourites with the star in the menu of the respective product. The list of recently visited pages has been removed.

Overlays darken instead of blurring

Drawers, dialogs and the quick search now consistently place a darkened background behind them. The previous blur made the image flicker while scrolling in tall windows.

Products are distinguishable at a glance

Several products carried very similar icons. Shop, ERP, Documents, Channels, People and MaaS now have their own, and in the product overview each gets its own colour.

Quick search now finds content too

The quick search (Cmd + K or Ctrl + K) used to match page names only. It now also shows which areas have something to say about your keyword, and below that the matching manual pages with the match highlighted. The three groups are visibly separated.

Search now finds products too

Type a keyword and matching products appear as their own group, ahead of the page results. Someone searching for "People" usually means the whole area, not one page inside it.

Sign-in asks for your account first

If you open the sign-in page through the general address instead of your company's own, you are now asked for your account first and then forwarded to your own sign-in page. Previously a form appeared there that could be submitted but could never work. Your account is remembered and prefilled next time.

Adding a passkey works again

Creating a passkey in your profile often showed "Registration challenge expired or not found" and the passkey was not saved. The cause was an internal short-term store that the servers did not share - depending on which server answered your request, the enrolment was lost between its two steps. You can add passkeys as intended again.

New product name: SELLERLOGIC Commerce Services

The platform is now called SELLERLOGIC Commerce Services (short: SCS). The former name "V3NDR" has been replaced throughout the interface, the manual and the e-mail templates. Only the name changes; your data, settings, logins and addresses stay exactly as they are, and there is nothing you need to do.

Sign-in: session protection is reliable again

SELLERLOGIC SCS now determines the address you connect from consistently everywhere. It previously used two different methods, which made your session's protection raise an alarm although nothing had changed - and once blocked sign-ins in July. Day to day nothing changes for you, but security limits such as "too many sign-in attempts" now apply per user again instead of to everyone at once.

Two-factor confirmation: a clear message instead of an error page

For security reasons, confirming with a passkey or recovery code is only valid for five minutes. If it took longer, SELLERLOGIC SCS used to report a technical error and any further input had no effect. You now see the notice "Confirmation took too long - please sign in again", and the sign-in form resets automatically so you can start over right away.

Permissions: you can only grant what you hold yourself

When creating or editing roles, assigning roles, and setting overrides, SCS now checks that you do not grant a permission your own account lacks. The highest roles "Owner" and "Super Admin" can also no longer be handed out through normal team management (Super Admin only by an Owner/Super Admin, Owner only by the Owner). Owners and Super Admins are exempt from this ceiling. This closes a gap that could have let team managers escalate their own rights.

Sign-in: issue fixed

A brief issue that prevented signing in to the administration area has been fixed. You can sign in as usual again. The "Last login" field on your profile page again shows your most recent sign-in time.

"Reset access" without re-onboarding

When an administrator resets a staff member's access, the staff member now receives an email to simply set a new password - instead of filling in the full onboarding form (name, profile) again. Account and profile remain unchanged; active sessions and two-factor data are still reset for security reasons.

Company address: country as a searchable dropdown

You now pick the company address country from a searchable country list - type "Germ", for example, and choose "Germany (DE)" - instead of the previous short choice (DE/AT/CH). The internationally standard country code is still what gets stored, and any country already on file is preserved. The intra-community VAT setting (seller's country of establishment) still uses the same value.

Settings: modernized, unified controls (part 1)

Usage and functionality unchanged.

Settings: modernized, unified controls (part 2)

Usage and functionality unchanged.

Help center & "?" button launched

SCS now has a built-in handbook. Use the "?" button in the top-right or the "Help" menu entry to open the matching explanation for any page - with search across all areas and thematically grouped area pages.

Manual in 44 languages

The complete manual is now available in 42 more languages in addition to German and English (machine-translated, English as the base). The language automatically follows your profile language setting.