 <p>Do you have an /app/templates/client-availibilities.hbs template with only {{outlet}} inside of it? Without this, the app is going to lose its place in the outlet tree. Ember-CLI and the Ember Starter Kit are very, very different from each other in structure, so I can see where the confusion comes from.</p> <p>How I like to think of Ember's rendering style is that each handlebars file inside the templates folder (i.e. /templates/users.hbs) represents a change the overall state of the application from one subject to another (example: from newsfeed to users). The corresponding subfolders inside the templates folder change the state of the subject itself. </p> <p>For example: </p> <ul> <li><strong>Required Templates</strong> <ul> <li>Users container OR the only users page you need app-wide is at /templates/users.hbs </li> </ul></li> <li><strong>Optional Templates</strong> <ul> <li>Users Index would be at /templates/users/index.hbs </li> <li>Users Show would be at /templates/users/show.hbs </li> <li>Users New would be at /templates/users/new.hbs </li> </ul></li> </ul> <p>You can have [ /templates/users.hbs ] without having [ /templates/users/*.hbs ] and still keep track of your data; however, you cannot have [ templates/users/index.hbs ] without [ /templates/users.hbs ] and still keep track of your data. Why? Imagine if you navigate to somesite.com/users. There is currently no top-level template with an outlet into which Ember can render the [ users/index.hbs ] template. The [ /templates/users.hbs ] template bridges that gap and also serves as a container for all other pages inside the <em>/templates/users</em> folder as well. </p> <p>For example, in the terms of your app, in order to render [ /app/templates/client-availibilities/index.hbs ] when a user visits <a href="http://www.yourwebsite.com/client-availibilities">http://www.yourwebsite.com/client-availibilities</a>, your app will need these templates defined so that ember can drill down into them. </p> <pre><code>application.hbs // and in its outlet, it will render... --client-availibilities.hbs // and in its outlet, it will render by default... ----client-availibilities/index.hbs // then, for the client-availability (singular), you can have ember render it in ----client-availibilities/show.hbs // will render also in the client-availabilites as it is a separate state of the subject. Can also be nested inside the index route within the router so that it renders inside the index template. </code></pre> <p>As it is, I would structure your app as such... </p> <p><strong>/app/router.js</strong></p> <pre><code>... // previous code Router.map(function() { this.resource('client_availabilities', function() { this.route('show', { path: '/:client_availability_id' }); // this.route('new'); ! if needed ! // this.route('edit', { path: '/:client_availability_id/edit' ); ! if needed ! }); }); ... // code </code></pre> <p><strong>/app/templates/application.hbs</strong></p> <pre><code>{{link-to 'Client Availabilities' 'client_availabilities'}} {{outlet}} </code></pre> <p><strong>/app/templates/client-availabilities.hbs</strong></p> <pre><code>{{outlet}} </code></pre> <p><strong>/app/templates/client-availabilities/index.hbs</strong></p> <pre><code>&lt;ul&gt; {{#each}} {{#if available}} &lt;li&gt; {{#link-to #link-to 'client-availabilities.show' this}} {{firstName}} {{lastName}} {{/link-to}} &lt;/li&gt; {{/if}} {{else}} &lt;!-- we want this to only render if the each loop returns nothing, which is why it's outside the if statement --&gt; &lt;li&gt;Nobody is available&lt;/li&gt; {{/each}} &lt;/ul&gt; &lt;!-- Note: you don't need to put an outlet here because you're at the end of the tree --&gt; </code></pre> <p><strong>/app/templates/client-availabilities/show.hbs</strong></p> <pre><code>&lt;!-- Everything you want to show about each availability --&gt;&gt; &lt;!-- Note: you don't need to put an outlet here because you're at the end of the tree --&gt; </code></pre> <p><strong>/app/routes/client-availabilities/index.js</strong></p> <pre><code>import Ember from 'ember'; export default Ember.Route.extend({ model: function() { return this.store.findAll('client_availability'); } }); </code></pre> <p><strong>/app/routes/client-availabilities/show.js</strong></p> <pre><code>import Ember from 'ember'; export default Ember.Route.extend({ model: function(params) { return this.store.find('client-availability', params.client_availability_id); } }); </code></pre> <p><strong>/app/models/client-availability.js</strong></p> <pre><code>import DS from 'ember-data'; var client-availability = DS.Model.extend({ firstName: DS.attr('string'), lastname: DS.attr('string'), available: DS.attr('boolean'), available_on: DS.attr('date') }); export default client-availability; </code></pre> <p>However, are you sure you want to structure your app by the availability of each client? Wouldn't it make more sense to structure it by each client and then just filter each client to show if they were available or not? Resources are supposed to be nouns, and routes are supposed to be adjectives. Therefore, it would be best to use a client as your model instead of their availability and have a either an isAvailable property on the model (as used in the example above) or a one-to-many association with an additional availability model if you want to show clients who have several availabilities (as shown below). </p> <p>For example, </p> <p><strong>/app/models/client.js</strong></p> <pre><code>import DS from 'ember-data'; var Client = DS.Model.extend({ firstName: DS.attr('string'), lastName: DS.attr('string'), availabilities: DS.hasMany('availability') }); export default Client; </code></pre> <p><strong>/app/models/availability.js</strong></p> <pre><code> import DS from 'ember-data'; var Availability = DS.Model.extend({ date: DS.attr('date'), client: DS.belongsTo('client') }); export default Availability; </code></pre> <p>In the long run, this latter approach would set up your app to show all availabilities at once and allow the user to filter by the client, plus it would allow the user to view a client and see all their availabilities. With the original approach (the isAvailable property on the client model), the user can only get the availabilities from the client model itself, but what if the user wants to see all clients who are available on, say, March 3rd at noon? Well, without an availability model associated with the client model, you are going to have to put a lot of code into your client controller that ember would give you by default if you go down the one-to-many path. </p> <p>If you need more advice on where to go from here, let me know. I'm more than happy to add more examples of the templates, controllers, and routes that you'll need in order to pull this off. </p>