Sharing an Item Within a Document, Not Entire Document

I have searched for this request to have been made earlier, because I can’t believe I’m the first one to request this, but haven’t exactly found it.

So, please make it possible to share an individual item within a document in the same ways it’s possible to share a document. I understand Workflowy supports this, but Dynalist does not.

That’s inconvenient. Right now, if I wish to share a portion of my document, I need to extract the item(s) from the document so that it becomes a separate document. Then I need to link back to it from the original document… It’s time-consuming and inconvenient.

Thank you for considering this.


Thanks for the feature request!

Here’s the previous post about it (and a link to our roadmap): Sharing of items in a list

1 Like

ALex_Avenarius, I am struggling with this as well.
Be mindful, anytime you linkback to another document you expose them both to access by the person you shared one to.
So when sharing DocB, a link back to DocA gives them access to it.

What I am going to try to do is rely on tags rather than links for cross connecting where I need to, BUT the problem is I may need the person with DocB access to also have access to something that must live in DocA domain.

I am working up a followup post for later with details for folks to review, and to see if there’s more interest (to prompt) in voting on this…

Share individual items on Dynalist Roadmap | Trello -



Thank you for your initiative on this, HTHawks! This is definitely one of the top “missing features” in Dynalist, and it especially compares negatively with Workflowy where sharing individual items of a list is highlighted as one of its top features to prospective customers… And no wonder – I would find it very useful on a daily basis, because I collaborate with lots of folks.


I’m going to chime in on Alex_Avenarius thread here (thank you for posting, and for your reply Erica).

@Erica, I am wondering if the Trello card is mislabelled , since technically “ListItem Sharing” is already implemented, but “Explicit listiem sharing” is the topic of concern here?

If it is the correct Trello card, I would encourage others who want this to please be sure to vote for it there if your interested! Trello.

@DEVS -technical challenge?:
I understand from general discussions on the board that “Explicit ListItem Sharing” (as I will refer to it herein) still may be a tall order for the Dynalist project …yes? If I were to guess I’d say the reason seems to be EITHER because of the current method employed for forming ListItem Hyperlinks (i.e. related to “/#=” used for those ) and server platform, AND/OR because handling locking out access to Parent/Ancestor Host Documents is technically counterintuitive to how its setup to work now?
I wonder if “Expiry Link generation” (if employed) would “happen” on another layer and possibly facilitate a solution? Unfortunately I don’t know anything about the development platform and server-hosting, so I really don’t know what I’m talking about -just tossing questions and ideas out in case it could be helpful.

Well I want to throw in my 2-sense Why I think “Explicit ListItem Sharing” seems significantly important for anyone working with other people. (@Moderator: if this seems like hijacking I apologize and please move it. It simply seemed more appropriate to not create yet another thread on this subject.)

So, because this is a little long (I am endeavoring to be detailed and comprehensive [hoping that’s helpful], while also endeavoring to keep focus on simplicity), here are…

Key Points List of this Post

  • Explicit ListItem Sharing, Expiring Links, and Encryption …potential features entanglement and possible need/value-priority
  • Identifying Common-Ground Usage Framework, Needs, Concerns, and Limitations (as I see it)
  • Demonstrating Value: Conceptual Framework + Map of what may be commonly required, followed by Challenge Notes, followed by…
  • Illustrative Example

Topic: Handling a PrimaryConcern/Entity, having multiple Projects, Resources, and People …All Overlapping.

  • …case review for the importance for being able to Share Individual ListItems Without Exposing the Host Documents (or “Explicit ListItem Sharing”). {with a comprehensive illustrative-Example}

PreNote: Entangled Techincal Concerns: It does well to point out up front that even if Explicit ListItem Sharing feature were provided, there would still exist the encomberment to “permissions access” control due to lack of Expiring/Managed Links feature in Dynalist. I.e., when things change you cannot expire the link and get a new one. I/we don’t know if Dynalist’s serverbase or codebase lends itself to setting this up, and even if it does, don’t know what that may entail.

  • Personally I would make Explicit ListItem Sharing the priority, i.e., at least have the power of separation from Parent Host material, due to the greater impact it would have on opening this project up to deeper and more flexible usage scenarios where more than one individual is involved (imho).
  • And I think “Expiring Links” would then be a next priority over “Encryption” for the same reason. Expiring links would lend good protection and facility for changes in people and resources-access control, whereas encryption, while beneficial, actually has lesser scope in these regards, and takes more effort to manage.
    Just my 2-sense here.

----- IN A NUTSHELL ------------
So let me begin by saying that I still have yet to learn more about Dynalist’s features, so there may be something I am overlooking here (that would be more helpful toward controlled sharing solution). All I know right now is you can make separate Docs, but that kind of breaks elegant organization and also relationships management.

What I mean by that is… say I have 3 Docs. It seems I can tag them up and explicitly share each one. If I have to connect two of them, I can post cross-links. But then, if I need to be crosslinking to any subListItems, I’ve just exposed the whole Host Doc. Not to mention as this progresses tag management becomes more and more tedious. If I then further break out more Docs, stuff becomes unweildy and messy …so this is simply not working.

• Common Situational Framework: I think most busy environments could be looked at as having these essential aspects…

  • I. Principle Concerns/Entities, each with multiple
    • A) Projects,
    • B) Resources/Aspects/Disciplines, and
    • C) Trades/People/Crews/Groups.
    • D) Locations and Times
      …so this is the scheme I am using for illustrative purposes here.

• Requirement: Discreetly/Explcitily Share a ListItem with someone(s) {associate persons or groups} where:

  • That/Those someone(s) may change.
  • That/Those someone(s) may be involved in different project aspects at various times, and
  • In some cases at more than one locale, or Zones at a Locale,
  • So they may require access to various ListItems, but without carte-blanche full access to a locale’s tasks or resource’s or other related stuff/data (i.e., full document or other documents).
    (Concept Framework and Example, and then a working Example appear below)

• Concerns and Limitations
Dynalist limitations I am running up against for this application are:
a) sharing a ListItem exposes everything in the host document
b) crosslinking to another ListItem in another document exposes everything (all other list items and linked items) in the other document(s) as well
c) Tagging instead of linking does not connect Document spaces’ ListItems when sharing only one of the documents (actually a Desireable feature in most regards),
d) some cases you want to use folder and multiple document management and others you may not want to, so… This functionality has its place for organizational management, not necessarily for controlling sharing permissions, and seems best determined by the user’s “brainscape” and not by a sharing management or other app limitation.

Additional problem I see is that, even if ListItem sharing is implemented, as relationships change, you cannot refresh/change/Expire Links for ListItems or docs, so link management is a related (potentially huge) challenge considering the sort of application being addressed here (which I would think would be quite common actually).

Related to this is Tag Breaking: while searching Same Named Tags in different documents can be performed by, and is helpful for, the list author, 1) this is not the case for shared documents and 2) if at some point you wish to change a tag, if you are forced to use many documents for a project concern, then you have to change/update each same-named tag in each document case.

CONCEPT EXAMPLE - Framework & Map (framework here is fictional, as my actual application is a bit more complicated, but framed-relationships accurately apply…)

Concern1 (an Entity) has

  • projects going on
  • at each of Locale1, Locale2, Locale3, Locale4, etc
    …and then…
  • various Tradespeople handling
  • various Aspects (Disciplines) like say …glass, wood, metal, paving, steel, water, security, automation, etc, AND/OR managing Zones at Locales
    …AND THEN…
  • there may be various Aspect Handlers depending upon what Locale, so for instance, wood-tradespeople1 handling Locale 1 + 2, but wood-tradespeople2 handling the other Locales, or Locale Zones. There may even be slight overlap to handle.

Don’t worry, it should become simply clear later in the example, this is a fairly standard demograph…

•CONCEPT MAP -4 Pillars
Example of General Tagging and Organization Structure (similar to what I have at this very infant stage of everything) looks like this:

  1. PrimeConcernDOCUMENT (<–a Dynalist Document)

  2. PrimeConcernDocument SECTIONS

  • “People Keep 'em spinning”: for daily/periodic tracking with agents
  • “People Tasks Tracking”: for tracking tasks under explicit stewardship by specific entities
  • “Locales / Zones Tasksheets”: for filling out and tracking explicit project zones’ needs+conerns
    **…**and then they are all readily interlinked primarily using tags
    Tag Group A: TIME stuff, like #Now, #Today, #Later, etc
    Tag Group B: TRADES/PEOPLE: @AdamA, @BarnyB, @ConnieC, @DavidD, etc
    Tag Group C: LOCALES: #Locale1, #Locale2, #Locale3, #Locale4, etc, (then there may be Zones as well)
    Tag Group D: DISCIPLINES: #Glass, #Wood, #Steel, #Rock, #Cement, #XYZSystems, #XYZResources, etc
    (Note: Those tag formats are morphing with multi-prefix assignments, but I’m not addressing that here. I’m trying to keep this real simple and straightforward [believe it or not]…)

  2. FILTER~SEARCH Example (the reveal/demonstration):
    Posted separately next, due to its length.

Challenge Notes:

  • Not everyone in Locale1 is supposed to have access to everything else going on there, however, I need to manage everything there “as one”. As well,
  • Some aspects of various Locales’ Projects intersect or overlap,
  • Not everyone dealing with a discipline, say Wood/Carpentry, is supposed to have access to all things Wood related, and
  • Some people work on one or more projects (per a specified discipline) in various locales and some do not,
  • Some people work on one or more disciplines at various Locales and not others.
  • Some people have greater oversight in areas than others.

Maybe a little confusing without an example, I know. The Filter~Search Example below (in the next post) should hopefully make clear why I identify this structure as fairly common (“simply”, I hope),

Dynalist offers a most liberating potential solution for managing project lists and tracking with “multi-faceted focus” with either the Concern, Locales, Resources and/or People involved. I find the tag-filtering system, and general organization, offered by the Dynalist project to be fairly matured, and the simple interface, but depth of features, --is very accommodating in many ways–, making this an exceptional tool. With explicit listitem sharing and some expiry linking I think this would jump light years ahead of the present market footing. (?)

If I understand correctly (from other discussions), the expiry-linking concerns mentioned above may not be able to be addressed in the near future(?). For a User To overcome expiry-link limitations I think one can copy everything into a new document, and then you have to tend to broken links. For smaller project concerns it may be worth it. Unfortunately sustainability is limited in a more weighted work environment.

If I had to choose I would live with the expiry-linking limitations concerns and push for explicit linkitems sharing (not exposing whole documents for the sake of a shared subitem).
For now it seems I would need to manually update people with exported copies or something similar =>work I was hoping to use Dynalist to avoid ;^).

Refer to the Filter~Search example below in the next thread (simple walkthrough).

I hope the above explanations provide some useful insight and may be helpful to further discussions on this concern. Please vote this up at the Trello if this interests you.

PLEASE VOTE! Share individual items on Dynalist Roadmap | Trello -

Related links

Sharing of items in a list - :star2:Features - Dynalist Forum

Sharing an Item Within a Document, Not Entire Document - :star2:Features - Dynalist Forum
Search results for ‘share item’ - Dynalist Forum


1 Like

Before I address your other points (might take a while, sorry!), may I quickly ask what do you mean by “ListItem Sharing is already implemented”? There’s currently no way to share it if it’s not the root item of a document. Did you mean you can send them a link to a specific item, while sharing the entire document?


Here I will try to illustrate what I think would be a typical application employing an outliner for project elements tracking, and the case for Exclusive ListElement Sharing (exclusive meaning sharing it won’t lend full access to the host document for the sharee).

Disclaimer: I am not an ace at GTD or related methods. My organizational approach is still very much a work in progress. As well, other related List aspects are not on display here (InBox, etc). That said, Please feel free to comment on anything.

**Main Doc: **

  • PrimeConcernDocument Sections (the main Dynalist Doc for this example)
    Primary Sections I-III
  • "People Keep 'em spinning": for daily/periodic tracking with agents
  • "People Tasks Tracking": for tracking tasks under explicit stewardship by specific entities
  • "Locales / Zones Tasksheets": for filling out and tracking explicit project zones’ needs+conerns
    **…**and then they are all readily interlinked primarily using tags

Tags Setup

  • Tag Group A: TIME stuff, like #Now, #Today, #Later, etc
  • Tag Group B: TRADES/PEOPLE: @AdamA, @BarnyB, @ConnieC, @DPeople4 to ZPeople26, etc
  • Tag Group C: LOCALES: #ALocale1, #BLocale2, #CLocale3, #DLocale4, etc, (then there may be Zones as well)
  • Tag Group D: DISCIPLINES: #Glass, #Wood, #Steel, #Rock, #Cement, #SecurityItem1, #SecurityItem2, #ElectricalResource1, #ElectricalResource2, etc, etc
    (Note: Those tag formats are morphing with multi-prefix assignments, but I’m not addressing that here.)

Example Filter~Search Criterion
Brief description of this ‘working’ example filter: I’m targetting a couple prime people working project aspects at 2 locales. One of the locales has 2 zones. Other people are involved in work at these locales. I want a quick overview of anything relevant to the two people/groups in question, with relation to #ALocale1, including anyone else tangentally engaged in job aspects with them there, AND I also then want a summary on #ALocale1 lists at the end.

The resulting list structure we’re after will resemble something like:
PrimaryConcernHavingManyProjects (doc)

  • People Keep 'em Spinin

    • @AdamA -call for things today
    • @BarneyB -call for things today
  • People Tasks Tracking

    • @AdamA
      • things to do
      • #ALocale1 things to do
    • @BarneyB
      • things to do
      • #ALocale1 things to do
    • @ConnieC
      • things to do per @AdamA or @BarneyB
  • Locales / Zones Tasksheets

    • #Alocale Tasklist
      • Stuff @AdamA is working on
      • Stuff @BarneyB is working on
      • Stuff being done elsewhere that is specifically related

Filter~Search Looks kinda like: ancestor:#ALocale1 -ancestor:#BLocale2 -#BLocale2 OR #ALocale1 -ancestor:#BLocale2 -#BLocale2 OR ancestor:@AdamA -ancestor:#BLocale2 -#BLocale2 OR @AdamA -ancestor:#BLocale2 -#BLocale2 OR ancestor:@BarneyB -ancestor:#BLocale2 -#BLocale2 OR @BarneyB -ancestor:#BLocale2 -#BLocale2

NOTE: I have limited the search criteria in the example, which is intended to be illustrative, and which technically might should include consideration for excluding other Locales.

Filter Logic Explanation: Because Locales 1+2 have intertwined concerns, and with the people in question as well, I need to use some separation in the filter logic, so…
::Get locale 1 stuff, i.e., anything tagged locale1 or with it as its ancestor, but minus the Locale2+ stuff:
ancestor:#ALocale1 -ancestor:#BLocale2 -#BLocale2
OR #ALocale1 -ancestor:#BLocale2 -#BLocale2
::Get group1 stuff, i.e., anything tagged group1 or with them as its ancestor, but minus focus on any of their work going on in Locale2:
OR ancestor:@AdamA -ancestor:#BLocale2 -#BLocale2
OR @AdamA -ancestor:#BLocale2 -#BLocale2
::Get group2 stuff, i.e., anything tagged group2 or with them as its ancestor, but (again) not focussing on any of their work going on in Locale2:
OR ancestor:@BarneyB -ancestor:#BLocale2 -#BLocale2
OR @BarneyB -ancestor:#BLocale2 -#BLocale2

Note1: Some #BLocale2+ stuff may still appear due to deep entanglements, but the focus will remain prominently on the desired objective -these two guys/gals/groups and Locale1

Note2: All references to an ItemX in this case include calls to both ancestor:ItemX and ItemX, but this is, obviously, not always the case. The ancestor feature in Dynalist provides flexibility in how one might employ ancestor vs individuated tagging -not uinder discussion here, but important to note.

Results -And so here we go. This is based on a realworld example, but with a totally ficitious framework.

. . note: I am not showing the whole document anywhere, only its conceptual structure map has been identified, and then this filter-result example.


    • Result: list limited to people in the filter call. I can immediately see whats on the front burner with the two people in question:
    • @AdamA- call per ruksor completion due in 1 week
      • she’s gotta followup on the XY Frame layout first
      • (entry hidden) something to do with #BLocale2
      • she’s flyin out to #CLocale3 on Wed (and this would be hidden as well if filtered same as #BLocale2)
    • @BarnyB- set plan shed on track4

    • Result: list based on people and their work at Locale1 per the filter call, minus their tasks at Locale2 (except for incidental entanglements, so then will pull in other relevant people and locales where intersections exist [hence @ConnieC below]). Gives me a good overview from a “working-crews perspective”, with focus on the relevant responsibilities of the primary people in the Filter-Query focus.
    • @AdamA (contractor) - ref on plan trak in proj2 book
    • -remove Carl off term p #ALocale1
      • followup on glassB frameW
      • [entry hidden] elect extension for R-term #BLocale2
      • needs to follow on new secsys co #CLocale3 [maybe hidden if #CLocale3 also filtered on]
      • (entry hidden) a description on thing to do with #BLocale2
      • another descrip per #CLocale3 in general [maybe hidden if #CLocale3 also filtered on]
    • @BarnyB (contractor) - set plan shed on track4
      • Get #Flocale6 #zoneX factor3 in order [maybe hidden if locale or zone filtered on]
      • start working plan for sub-section A, must review with @PersonZ (owner)
      • #ELocale5 replacements need substrate comp [maybe hidden if locale filtered on]
      • ask about the new *#zoneV [maybe hidden if zone filtered on]
    • @ConnieC (controller) - ::trak/report
      • #ALocale1 Bus and Auto+Sec System budget review

    • Result: list based primarily on relevant Locale(s) in the filter call. So below the above trimmed down work-crew overview I then get here an overview of the relvant Locale(s) / Zone(s).
    • #ALocale1 (from the Filter Query)
      • #ZoneT
        • @AdamAand @BarnyB Access changes
            • more sub stuff
            • more sub stuff
        • @BarnyBand @DPeople4 meet routing when ADelta met
            • more sub stuff
            • more sub stuff
        • 2ndary storyboard on Elecy
            • Sub1 stuff
                • more sub stuff
            • Sub2 stuff
                • more sub stuff
      • #ZoneYY (another zone in ALocale1)
        • @ZPeople26 and @BarnyB Delta Bravo
            • more sub stuff
            • more sub stuff
        • @BarnyB and @XPeople24 conf post #DeltaB
            • some sub stuff
        • Transfer over to #ZoneB
            • Sub1 stuff
                • more sub stuff
            • Sub2 stuff
                • more sub stuff
    • #BLocale2+ [any jobsites without reference to one of the people on the filter will be suppressed, but if one of them has related work at an otherwise excluded site, that list item will be displayed
      • Send updated sitemap to @BarnyB
        • subnotes
      • [all other entries for site are hidden (not relevant)]


WITH EXPIRING LINKS, ONE COULD HAND OFF AUTHORITY TO SOMEONE ELSE, AND/OR RETIRE AUTHORITY ALTOGETHER (but right not you cannot change the link or access to it -big problem!)

I hope this conceptual description and example are useful in providing prime insight into

  • how powerful Dynalist can be for quickly bringing focus onto a multiplicity of aspects of an explicitly extracted areas of a broad job/concern …that exists within a deeply diverse host-concern having many jobs. And…
  • how valuable a tool Dynalist can be for doing this, And…
  • how much greater value it would have if ExplicitListItem Sharing, as well as Expiring Links were onboarded (game changer).

Thank you for you interest.
Thank you Dynalist team for the inspiring project.


Right, no way to do that right now. And I’m missing that feature every day. For example, we’re hiring a web developer for a one-off project right now, and instead of me being able simply to share my notes and instructions with him from within my main Dynalist doc, I first need to transfer those notes to a separate new doc before I can share them with him and others. Quite a runaround.

And yes, @HTHawks, I’m aware I can only use internal Dynalist links from a private doc/item to a shared one, but not vice versa, because that might expose my private content to anyone clicking the link. It’s definitely a risk unless you pay attention to what you’re doing.

In any case, thank you, @HTHawks, for approaching this feature request in such a thorough, scholarly manner! :slightly_smiling_face: I think we can all agree that this is a feature that we may reasonably demand from Dynalist, given that it’s one of the “showcase features” for Dynalist’s competitor WorkFlowy. (And I kinda automatically expect Dynalist to be ever-so-slightly better than WorkFlowy in every aspect.) :wink:

1 Like

Yes, @Erica, I meant you can get a link for any ListItem and send it to someone, but then they have access to the Parent Document from there.

I TOTALLY Appreciate it is some long-a$$ stuff I posted, and will take some time for any review and consideration.

I wanted to be sure to make a comprehensive case and back it up. The case is, people deal with projects, sometimes having multiple aspects, then you have people, things, places, and time.

The filter-search example demonstrates how, even in a seemingly unweildy and complex depth of a situation, Dynalist is the sort of tool one could use to tackle tracking effectively, but then sharing adds another set of complexities.

I figured it does well to break it down to see just what that may look like …in case it helps tie these conceptual concerns together. (and to illustrate the potential value for consideration)



Thank you @Alex_Avenarius