Ok, but I believe this is exactly what @BLUEFROG advised me to do – unless I’m misunderstanding a key part of the instructions (which is certainly possible!).
I can certainly provide that, but I’m not sure what it’ll help illuminate. The smart rule just creates another set of groups, under the following group structure:
| GORILLAS | |
|---|---|
| 3. Articles | |
| -RAW |
I’m copying the same smart rule that you created per your earlier post / instructions…
…while only changing the file path to…
Why do you have a pipe (|) in front of the Aliases token in your smart rule?
Just checked my smart rule, and no such pipe (|) exists in front of the Aliases token.
Should I change any other smart rule settings so that it moves (Files) files into groups instead of creating a new set of groups? And is there something else I can do to ensure that I can apply the smart rules to the source groups (where I’m first depositing files)?
Thanks again.
It must be the cursor in your screen capture then.
Yes you could use the Move action to pinpoint specific groups. But you cannot use the method suggested by @cgrunenberg (or my variation). You will have to create smart rules per-subject / per-destination group / etc.
Just tried this successfully again, no additional groups are created if the case of the File action is identical to the case of the existing groups.
Correct and that’s definitely the expected behavior.
I think @jprint714 was referring to a new hierarchy being created instead of going into an existing one.
…and therefore I wonder whether it’s a matter of the case (sometimes uppercase is used but not always in his examples).
Can you clarify what you’re referring to?
Is it a matter of new groups with names having a different case or wanting to file into an existing group structure and the smart rule is creating a new structure altogether?
See…
E.g. Articles vs. ARTICLES, -RAW vs. - Raw, Gorillas vs. GORILLAS etc.
The smart rule creating new groups as the case of the input of the File action does not match the case of the existing group names. It’s case sensitive.
In this hierarchy, including the Path bar, what would be the Top Group Name…
I though it would be Articles or Inbox, but it appears to be the database name 6.
Unified inboxes? Then this is currently correct (but not sure how that’s related to the above issue).
It still uses the database name, even if the Inboxes aren’t unified.
And I was looking at a way to create a unified smart rule that would use the group name as the main group to file into and the top group name as the subgroup.
Should be possible if it’s not inside the local inbox.
So this works, but it obvious requires uniformity in group naming and the groups are at the root of the source database…
After dropping a file into an article and a document group for Gorillas…
@jprint714 : Take special note of the uniform group names in the source and destination database’s group structures.
You could create a smart rule for Articles and one for Documents to relax this requirement a little but this is showing a possible solution as well as why it’s best to be uniform as much as possible.
Thank you ever so much for this @BLUEFROG ! I’m very grateful… And I’m sorry to take so long getting back to you – I was just in transit when you put this up. I’m going to set this up right now, and might have quick questions or two for you along the way…
Here are some quick ones: Will this smart rule work for groups in my Global Inbox that already have existing files? If not, how can I trigger the smart rule so that it moves those files?
Also, like I said, I’ve got about 20 groups in my Global Inbox. Is it possible to use one smart rule – with the configurations you’ve created here – for all 20 groups? Or do I need to create 20 smart rule for each group?
Thanks so much again… I’m setting this up right now. Thanks!
You’re welcome.
It’s not going to work completely out of the box unless you have conforming group names as I’ve indicated above.
The smart rule I posted is based on a very uniform naming convention, i.e., the groups receiving data are named the same as the destination groups.
If you’re varying from this, then yes, extra smart rules will likely need to be employed.
Also, bear in mind I am presenting a smart rule requiring no Execute Script actions. Obviously the options are more powerful when using one but not everyone is inclined to scripting and smart rules should be accessible to everyone.
I think I follow what you’re saying here re: uniformity of groups. So, in this example I would need to have Global Inbox>Articles>GORILLAS and then Active Projects [database] >GORILLAS>3. Articles>- Raw (I use a hyphen and a space before “Raw” – and I used it uniformly).
In other words, this smart rule won’t work if one group is named GORILLAS and the other is Gorillas – or if on the receiving end there RAW / -Raw / - raw , correct? Everything has to be uniform or it won’t work. Have I got that right?
BTW, just so I can better understand how these things work, would Group Name refer to “3. Articles” and does Top Group Name refer to “GORILLAS” (under the Active Projects database)?
Thanks again!
You’d need both the case-sensitive Gorillas and the full group name, e.g., 3. Articles in both places.
In the receiving groups, the Top Group Name is 3. Articles, 4. Documents, etc.
The Group Name is the animal name here.
Aha! I’m so glad I asked as I feared that I was overlooking a key element! I think I’ve got it sorted out now. I’ll circle back w/ an update. Thanks so much, @BLUEFROG !
You’re welcome.
