Hi everyone, new here and already causing trouble 😅. I'm trying to get our team set up with SciSpace for literature reviews, but I'm really confused about the shared library permissions.
We have junior members (interns, basically) who need to read and organize papers, but the default settings seem to let them delete folders or entire collections? That can't be right. I'm terrified one of them will accidentally nuke our main project library. I tried looking at the roles, but it's not as clear as something like WordPress.
Has anyone else run into this? Is there a way to set it so they can add and tag, but *not* delete or move things out of the library? I'm probably missing something obvious, but any guidance would be a lifesaver!
You've hit on a fundamental permission model flaw that's common in these collaborative platforms. The issue with SciSpace, and similar tools, is that "organize" often intrinsically includes delete and move permissions; the system assumes organization is a singular privilege. What you're looking for is a distinction between *curation* (add, tag, sort within a structure) and *governance* (modify the structure itself).
You likely need to explore if SciSpace has a custom role feature, or if their "Member" role is truly all-or-nothing. If there's no granular control, you're forced into a procedural workaround: implement a strict naming convention for folders and use a separate, read-only reference library that juniors cannot write to. They would add and tag papers in a staging area, which a senior member periodically reviews and migrates.
Also, check if there's an audit log or version history feature. A proper system should have immutable logging of delete events, allowing for recovery even if the permission model fails. If it doesn't, that's a significant red flag for academic work.
You're right to be worried, it's a genuine risk. SciSpace's permission model is frustratingly coarse-grained for team use.
Check if your workspace is on a paid plan. Some platforms hide granular role management behind the first paid tier. If you're on a free plan, you're likely stuck with the all-or-nothing "Member" role, which is a common vendor tactic to push upgrades.
Your workaround, for now, is to create a separate "Staging" library where they have full member access. Your core library should be restricted to senior staff only. They add and tag in Staging, then someone with governance rights moves the vetted items over. It's inefficient, but it prevents catastrophic deletion.
Your cloud bill is 30% too high
Yep, the paid plan check is spot on. I've seen that same pattern with other SaaS tools, where the free tier is a demo of teamwork, not real teamwork.
The staging area workaround is exactly what we had to do, and it created a new problem: version drift. When someone forgets to move things over, the staging library becomes the de facto source of truth, and then you're managing two messy libraries. We solved it with a weekly calendar reminder for the "librarian" role, but it's definitely process glue.
You're not missing anything obvious, the permission model just isn't fit for purpose. I ran a benchmark on this kind of issue last year, tracking how many distinct actions each platform decouples. SciSpace grouped "Add" and "Delete" under a single "Edit" permission, which is fundamentally broken for team use.
Check for a "Contributor" role, which some platforms hide. If it doesn't exist, you have two bad options: the staging library workaround people mentioned, which adds operational overhead, or you script a daily backup of your library structure to an immutable store (like an S3 bucket with versioning) so you can at least recover from a deletion event. Without that safety net, your fear is completely justified.
FinOps first, hype last