Organic Groups is one of those modules that have had major changes beween Drupal 6 and Drupal 7. While the D6 version (due to legacy) had its own solutions for lists, group audience and other things, the new version utilizes entities and fields to its fullest – and relies on Views for creating lists of just about any type.
The benefits of not creating its own solutions for associating data with entities and creating lists is greatly increased flexibility. The Drupal 7 version will not – like the D6 version – have sub modules like Organic Groups Flick block, Organic group profiles or other modules that provide functionality that you normally expect to get by combining OG with your Drupal framework module of choice.
The cost of relying on other modules, though, is increased complexity. Organic Groups comes with a nice example feature that sets up the most common configuration in a snap, but to really make use of the module you need to know how to use relationships and contextual filters in Views, how to use relationships and Views content panes in Page manager, and how access and utilize data in Rules.
The screencast series Learn Organic groups tries to explain how to use OG and make the most out of it, by using it together with other important Drupal modules. I hope it will be useful for you.
PS: Also check out Amitaibu's suggestion to rewrite the references for Organic groups, and the excellent screencasts about OG over at ModulesUnraveled!
Photo credit to krayker at rgbstock.com

Comments
walter
December 3, 2011the site is a nonsense at all. I miss the old one.
Christian Okpada
December 9, 2011@Walter: you right.
@nodeoneI wonder why you guys changed your site. Change is only a good thing if it's for the best...but this change you made failed.
Ryan
December 13, 2011I've been running around in circles trying to figure out whether OG is the right solution to what I'm trying to do. My site consists of writers, the companies they represent, and the content that they create. For the sake of simplicity let's just say they're writing articles.
Here's what I'm trying to achieve:
When a writer publishes a piece of content I want to add an author box and a company box (the writer's company). Then I want that content to be streamed on the company page that's associated with that particular writer (in some cases there are more than one writers from the same company). One thing I need to keep is final editorial rights to publish with Workbench.
So as an end result I'm envisioning:
A company page that lists the content from the writers that are associated with the company;
Writer profile pages that reference the company they belong to and the content they've published;
Published content that displays some fields fields from the company page and the writer's profile;
I get final editorial discretion (Workbench) before the content is published
I've looked through the forums and I've read somethings that kind of applied to what I'm trying to achieve, but either the question wasn't all that well put or the use case was simply different.
A couple of approaches that I've tried so far have been:
Organic Groups - (Why Workbench was brought up at all) - I thought if I made a content type "Company" into a group and then designated "Articles" to be group content I'd have the link between writer, company, and content taken care of. One thing that kinda drove me nuts was "audience" because any articles that were going to be published would either pass editorial discretion and be seen by everyone or it wouldn't be seen at all. The little idea here was that I would get the groupings, but make the content visible to all (members of the group or not) so I could have the connections I was looking for.
Unfortunately, from what I can tell I run into that audience box and I don't really relish having that show up to end users. Also, since Organic Groups have their own little hierarchy of moderation it didn't really seem like my Workbench editorial flow control was going to fly with this approach. I just about got the hang of OG for its intended purpose, but the whole time I felt like I was trying to make it do something it wasn't really geared up to do. On the other hand I'm sure there's a lot of brilliant people out there who have done crazier things with OG that can help shed some light on this approach!
Profile2 This one I'm a bit ashamed to admit, but maybe there's hope lol So what I did here was attempt to create a Public "writer profile" for the writers themselves along with a second profile "company profile." I thought maybe what I could do here was have them create the company, reference the writer profile in it, then add (maybe User Reference) other writers from their company to pull their names and content into the company profile.
However, Views always seemed to be on thin ice and the URLs/Tokens/Pathauto just didn't seem to be there to accomplish what I was looking for. I'm thinking sitename.com/profile/[first:last] for the writer profile and sitename.com/company/[companyname] for the company profiles. Then also have views listing profiles (sitename.com/profiles) and companies (sitename.com/companies).
Right now I'm turning to References with the hope that if I use the stock profile entity that maybe I can use Context + Views blocks to piece together a dynamic Profile page that can be referenced by a Company node where the original Company node creator can User Reference his coworkers... this I'm still navigating by candlelight and have no idea if it'll swing or not.
On the otherhand it seems there's the Relation module which as I understand is supposed to be the 'more handy capable' version of references, but I don't know enough about it to give it a real college try. Could this be a use case for it?
Finally, one other method I've seen is to take the Taxonomy route and create a Vocabulary called Companies and the terms would be company names. I think I ran across this idea for creating directories, but I really don't know if it's a plausible solution for what I'm shooting for...
Am I missing the mark with OG or are relations or reference the way to go on this?
Johan Falk
December 13, 2011 Generally I can't take on large questions like these – it is better to post on drupal.org and leave a link in a comment here. That way, many more can take part in reading both question and answers. Having that said, I think this sounds like an excellent case for Workbench Moderation, combined with Workbench Access. When it comes to making lists of content, Views is what you want. But Workbench will take care of the workflow. (It could probably be done with OG as well, but it will be trickier to get the moderation going.) Good luck!