There is no way to decide whether or not to write an integration test that you can use without thinking. Any real application has nuances and special cases that challenge any rule. But there is certainly a common approach which you can follow except in cases where you find it doesn't fit: the approach of using acceptance tests as integration tests.
Side note: I'm taking "integration test" to mean a test which exercises more than one layer of your code, not the Rails-specific meaning which has mostly been subsumed by better methods and tools. But my answer applies if you do use Rails integration tests.
An acceptance test captures an important user flow. It is also an integration test, exercising all layers of the application from UI all the way through the back end. Behavior-Driven Development (BDD) and similar methodologies drive development outside-in by writing acceptance tests for all important user flows. Acceptance tests are complex to write and slow to run, so one tries to write the smallest number of them possible which still defines all important user flows.
Choosing acceptance tests is an art, but a rule of thumb is that if two scenarios involve different actors and/or different major system components (e.g. UI screens) they should have separate acceptance tests, and if not they're the same scenario with details and one acceptance test is sufficient.
Acceptance tests are useful in communicating with your stakeholders (i.e. recording requirements), so you want them regardless of the rest of your testing strategy. But it's common to find that a full set of acceptance tests is all the integration tests that you need. Detailed requirements that don't merit acceptance tests can be expressed in unit tests.
In your example, I would probably write one acceptance test for a scenario where a user creates their own appointment and another for a scenario where a parent has to help, because they'd be quite different. The first would be something like (using Gherkin)
When I visit the new appointment page
And I create a new public appointment
And I visit my calendar
Then I see the public appointment
but the second would be quite different:
When there is an unrestricted user "Dad"
And there is a restricted user "Billy" supervised by "Dad"
And there is a user "Stalker"
When "Billy" visits the new appointment page
And "Billy" creates a new appointment
And "Billy" visits his calendar
Then "Billy" sees a pending appointment
When "Stalker" visits "Billy"'s calendar
Then "Stalker" does not see an appointment
When "Dad" visits "Billy"'s calendar
And "Dad" approves the pending appointment
Then "Dad" sees an appointment
When "Billy" visits his calendar
Then "Billy" sees an appointment
When "Stalker" visits "Billy"'s calendar
Then "Stalker" does not see an appointment
On the other hand, I would probably not write two different acceptance tests for scenarios with and without a location (assuming that location is just a text field that might or might not be filled in). Unit tests would probably suffice there.
